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SAMMANFATTNING 


Bakgrund och syfte med projektgenomlysning 

Naturhistoriska riksmuseet (NRM) inledde 2009 formellt DINA-projektet. Syftet med projektet var 
att ta fram ett samlingshanteringssystem med potential att hantera alla naturhistoriska samlingar 
inom NRM men även andra museer. Sedan start har projektet utvidgats och ändrat inriktning. 
Idag består DINA-projektet av en projektorganisation inom NRM samt samarbete med två 
grupper: DINA-SE som utgörs av en grupp svenska museer, samt DINA-INT som är en 
internationell gruppering. Utöver utökat antal involverade parter i projektet har ambitionen, 
omfattningen och komplexiteten ökat vilket medfört att tidsplaner försenats, bristande översikt av 
kostnader och oklarheter avseende styrning och målsättning för projektet. 


Mot den bakgrunden har den nyligen etablerade ledningsgruppen i NRM, på beslut av 
överintendenten, inlett en översyn av projektet för att utvärdera arbetet och resultatet hitintills, 
samt fastställa den framtida inriktningen för DINA-projektet. 


Syftet med denna rapport är att redovisa resultatet av projektgenomlysningen av DINA-projektet 

med fokus på: 

e Styrning och ledning av projektet 

ee Ekonomisk sammanställning samt grad av kostnadskontroll inom projektet 

« Redogörelse för samarbete med externa parter samt eventuella krav som finns på NRM 

« Utredning av det tidigare vägvalet egenutveckling samt rekommendationer avseende framtida 
vägval för DINA-projektet 

e - Förslag och rekommendationer för vidare inriktning och arbete för DINA-projektet. 


Bristande projektgenomförande och ekonomisk uppföljning 

Analys av genomförandet av projektet påvisar flera brister i styrning och uppföljning, tillämpning 
av gängse projektmetodik, otydlig målbild, bristande dokumentation av krav, samt avsaknad av 
kritisk kompetens inom projektledning, förändringsledning och IT-utveckling. Vidare saknas en 
regelbunden ekonomisk uppföljning och kontroll vilket medför bristande insikt i nedlagd tid och 
kostnader. Den ekonomiska redovisningen av DINA-projektet visar att ca 26,2 mkr eller 
motsvarande 43 000 timmar har förbrukats sedan 2012. 


Starkt samarbete med nationella och internationella museer där arbetet tilltar 
DINA-projektet har inlett samarbete med flera nationella och internationella museer som delar 
ambitionen av att etablera ett gemensamt samlingshanteringssystem. Analysen påvisar dock 
otydligheter i koordinering mellan de olika grupperingarna. Under 2020 kommer två museer att 
investera flera resurser i utvecklingen av DINA-Web, vilket medför att NRM bör klargöra sin roll i 
DINA-INT gruppen framöver, mot bakgrund av en otydlig målbild och plan för projektet. 


NRM rekommenderas att överväga inköp av tjänst eller system som framtida vägval 
Analys av genomförandet av egenutveckling av DINA-Web påvisar flera brister i genomförandet: 
otydlig målbild, ofullständig insamling och dokumentation av krav, bristande kommunikation och 
förankring med verksamheten samt avsaknad av kritisk kompetens inom projektledning, 
förändringsledning samt informationsmodellering och IT-arkitektur. En jämförelse med andra 
organisationer avseende vägval mellan egenutveckling och inköp stödjer denna slutats. 


Mot den bakgrunden rekommenderar Ramboll att NRM utvärderar externa alternativ tillsammans 
med SPECIFY och DINA-Web samt utvalda befintliga system. Utvärdering bör baseras på en tydlig 
gemensam målbild samt överenskomna och prioriterade krav. Vidare bör projektet mobilisera 
kritiska resurser samt applicera PPS som metod för genomförande och styrning av projektet. 
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INLEDNING 


2.1 Bakgrund 

År 2009 inledde Naturhistoriska riksmuseet (NRM) formellt IT-projektet DINA (2009-03-10 Dnr 
52-276/2008). Syftet med projektet var att ta fram ett samlingshanteringssystem med potential 
att hantera alla naturhistoriska samlingar inom NRM. Samlingshanteringssystemet skulle även 
göra det möjligt för alla potentiellt framtida deltagande museum att effektivt kunna hantera sina 
samlingar, samtidigt som tillgång till samlingsdata skulle ges till externa forskargrupper och andra 
utvalda intressenter. 


Sedan projektstarten har projektet ändrat inriktning, omfattningen av arbetet förändrats 
och nyckelpersoner i projektet har slutat och ersatts med nya. Idag finns även både en 
svensk och en internationell gruppering av museer med intresse och engagemang för 
utvecklingen av DINA. Projektet har dock påvisat en begränsad leverans vilket medfört 
frågetecken från både interna och externa parter. 


Den senaste gällande projektplanen med fokus på att utveckla ett system med kapacitet att 
hantera utvalda naturhistoriska samlingar löpte ut 31 december 2018. Överintendenten för 
Naturhistoriska riksmuseet beslutade då att utvärdera projektet. Bakgrunden är främst de ökade 
kostnaderna, försenade leveranser och oklarheter om förväntningar kring projektet från de 
involverade intressenterna (både interna och externa). 


Denna rapport är en del av en total genomlysning av projektet som överintendenten, tillsammans 
med den nyligen tillsatta ledningsgruppen, beslutade att genomföra. Rapporten kommer att ligga 
till grund för beslut avseende inriktning, omfattning och plan framåt för DINA-projektet. 


2.2 Syfte och metod för genomförande 

Rambolls uppdrag är att ge ett externt perspektiv på DINA-projektet och därmed utgöra en del av 
det beslutsunderlag som överintendenten för NRM efterfrågat. Fokus i Rambolls arbete och denna 
rapport är att ge vägledning avseende val av inriktning samt rekommendationer för 
tillvägagångssätt för vidare arbete med DINA-IRIS projektet. 


För att kunna leverera ett gediget beslutsunderlag omfattar utvärderingen följande områden: 

« Analys av projektets styrning och organisering samt tillvägagångssätt hitintills som grund för 
rekommendationer för hur projektet bör drivas framöver. 

. - Genomlysning av hitintills nedlagda kostnader samt applicerad metod för kostnadskontroll 
inom projektet. 

. Beskrivning och analys av de fördelar, nackdelar och risker mellan vald väg för egenutveckling 
i jämförelse med inköp av system eller tjänst. 

. - Genomlysning av samarbetet med externa aktörer samt vilka förväntningar och eventuella 
krav som finns till NRM. 

e Förslag och rekommendationer om vilka åtgärder som behövs för att säkra bästa möjliga väg 
framåt, oavsett vägval, för att nå målet. 


Utredning, sammanfattning och rekommendationer bygger på dokumentstudier samt intervjuer 
med tio utvalda medarbetare på Naturhistoriska riksmuseet samt en extern aktör från 
Evolutionsmuseet vid Uppsala Universitet. Intervjukandidater har utsetts av Naturhistoriska 
riksmuseet i diskussion med Ramboll. 


2.3 Begränsningar i utredning 


Då DINA-projektet har pågått i närmare tio år är det förväntat att projektet har haft många olika 
'faser', att många personer har varit involverade samt att det finns en ansenlig mängd 
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dokumentation. Mot den bakgrunden samt omfattningen av Rambolls uppdrag med fokus på 
rekommendationer för framtida inriktning och arbetssätt, har utvalda dokument och personer 
legat till grund för analys och rekommendationer som presenteras i rapporten. 


2.4 Terminologi 

Utredningen av DINA-projektet berör många olika områden, såsom IT-utveckling, DINA-specifika 
termer och verksamhetsutveckling. En fullt naturlig utmaning i ett projekt av denna komplexitet 
är olika uppfattning av terminologi. Därför har Ramboll författat en lista med några av de 
nyckelbegrepp som används i denna rapport under Appendix B. 


DINA-projektet har gått under olika namn såsom IRIS, DINA/IRIS och bara DINA. I denna rapport 


benämns projektet som enbart "'DINA-projektet' men det avser även övriga benämningar som har 
använts under projektet. 
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SAMLINGSHANTERING VID NATURHISTORISKA 
RIKSMUSEET 


3.1 Introduktion till Naturhistoriska riksmuseet 


Naturhistoriska riksmuseet (NRM) är en myndighet under kulturdepartementet och ett av 
Sveriges äldsta museer. NRM har en viktig uppgift att vårda, dokumentera och utöka de 
naturhistoriska samlingarna, bedriva relaterad forskning och den publika och pedagogiska 
verksamheten!. I uppdraget ingår även att förbättra förutsättningar för samlingarnas bevarande 
och öka tillgängligheten till samlingarna. Visionen för NRM är: 


"Vi ökar kunskapen om naturen och inspirerar till ansvar för vår värld.” 


Naturhistoriska riksmuseets organisation 

Naturhistoriska riksmuseet består av tre avdelningar med totalt 14 enheter under ledning av 
överintendenten. Av de totalt 14 enheterna bedriver sex stycken forskning inom respektive 
område. 


Överintendenten 


Bioinformatik och genetik (BIO) Kommunikation (KOM) FR 


Botanik (BOT) Utbud (UTB) IT-stöd (ITS) 


Geovetenskap (GEO) Värdskap (VÄR) Personal och kompetens (POK) 


Miljöforskning och 


övervakning (MFÖ) Lokaler, arkiv och registratur (LAR) 


Paleobiologi (PAL) Drift (DRI) 
Zoologi (ZOO) 


Figur 1: Organisationsstruktur för Naturhistoriska riksmuseet 


3.2 Summering av samlingshanteringssystem 

Inom NRM finns idag flera system som innehåller information (bilder, text, filmer m.m.) om 
museets samlingsobjekt. Då det saknas en gemensam, enhetlig hantering av samlingarna har 
respektive enhet under avdelningen för forskning och samlingar (FA) egna och unika databaser 
baserat på olika tekniker och programmeringsspråk. Ett betydande antal objekt har ännu inte 
digitaliserats. Nedan är Rambolls förståelse av nyttjade samlingssystem i dagsläget per enhet. 


1 Strategisk plan för Naturhistoriska riksmuseet 2019-2022 
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Befintliga samlingshanteringssystem inom NRM 


RO DINA Sequences (DNA-arkviet, SeqDB) 
Botanik (BOT) FileMaker 
Geovetenskap (GEO) Specify 
Miljöforskning och ESPASE (php och MySQL) 


övervakning (MFÖ) 


Paleobiologi (PAL) FileMaker, Paradox 
FileMaker 
Zoologi (ZOO) rer 


Vissa texter och bilder i mappar 


Figur 2: Systemöversikt över befintliga samlingshantering per respektive forskningsenhet 


Det finns, i varierande grad per enhet, objekt som inte är digitaliserade. Arbetet med att 
digitalisera dessa är under planering eller pågående. Huruvida det sker i koordination med DINA- 
projektet är oklart. 


3.3 Strategisk plan för Naturhistoriska riksmuseet 2019-2022 

NRM är en organisation bestående av ett antal avdelningar och enheter med delvis individuella 
mål och ambitioner. För att tydliggöra gemensamma mål och aktiviteter för kommande år har en 
strategisk plan tagits fram. I den strategiska planen framgår NRMs målbild, uppdrag och vision 
samt plan med initiativ för att uppnå de strategiska målen för 2019-2022. Syftet med den 
strategiska planen är att få en mer enhetlig och samordnad myndighet. 


Det första strategiska målet i den strategiska planen är: ”Vi säkerställer samlingarnas aktualitet 


och långsiktiga bevarande samt ökar deras digitala tillgänglighet”, där en av de fyra prioriterade 
aktiviteterna för måluppfyllnad är: 


”Museets samlingshantering samordnas genom en museigemensam systemlösning, i enlighet 


med plan för detta som läggs fast under 2019. Vår lösning kan på sikt användas av andra 
naturhistoriska samlingsförvaltare i landet som så önskar.” 


Formuleringen av aktiviteten ger en tydlig inriktning för DINA-projektet och ligger således till 
grund för Rambolls rekommendationer för framtida vägval. 
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3.4 Överblick av DINA-projektet 

Diskussionerna om ett gemensamt samlingshanteringssystem på nationell nivå påbörjades någon 
gång under 2007-2008 när flera naturhistoriska museer i Sverige beslutade sig för att genomföra 
en förstudie för att bl.a. utvärdera olika lösningar för samlingshantering. 


Sedan dess har arbetet och andelen intressenter ökat inom DINA-projektet, både på nationell och 
internationell nivå. Idag består DINA-projektet av två grupperingar med olika medlemmar: 

e - DINA-SE som omfattar de svenska deltagarna i DINA-programmet. 

e - DINA-INT som omfattar de internationella deltagarna i DINA-programmet. 


Medlemmar i DINA-projektet 


« Agriculture and Agri-Food Canada, Ottawa, Evolutionsmuseet, Uppsala 


Kanada | « Biologiska museet, Lund 
« Museum fär Naturkunde, Berlin, Tyskland + Göteborgs naturhistoriska 
« Tartu Natural History Museum, University of museum, Göteborg 


Tartu, Tartu, Estland 


»« Statens Naturhistoriske Museum, 
Kgobenhavns Universitet, Köpenhamn, 
Danmark 


« Royal Botanic Garden Edinburgh, 
Edinburgh, Storbritannien 


« Herbarium GB, Göteborg 


Figur 3: Medlemmar i den svenska och internationella grupperingen av DINA-projektet 


Tidslinje över DINA-projektet 

Sedan start har DINA-projektet genomgått ett antal ”faser” och levererat ett antal lösningar och 
delmål för enheter inom NRM och övriga medlemmar i den svenska och internationella 
grupperingen. 


Tidslinje över DINA-projektet 


Egenutveckling DINA-web 


Samverkan med Specify-teamet (DINA- 
Specify) 


a br TTG RT SAR ARN RT ENA TR TEATER LR RAT RT RN RT TATT RTR RAN ARG 


DINA-SE och DINA-IRIS Specify version 6 


Projektstart börjar användas DINA-programmet 
DINA-INT: Specify version 7 DINA Collection 
Memorandum of Understanding (webbaserad) ute för test på 
lanseras ZOO 


Figur 4: Övergripande tidslinje av DINA-projektet från 2009 till idag 
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Något förenklat kan projektet delas upp i två faser där Specify var i fokus inledningsvis följt av en 
andra fas med fokus på egenutveckling av ett system (DINA-WEB) 2014. 


3.4.1 Redogörelse av utfall i arbetet med Specify 

Under åren 2010-2014 fokuserade DINA-projektet på samverkan med Specifyteamet vid 
University of Kansas. Syftet var att möjliggöra användning av Specify som gemensamt 
samlingshanteringssystem genom att komplettera systemet med komponenter utifrån NRMsS 
särskilda behov. Samlingshanteringssystemet är idag mer känt som DINA-Specify och används 
inom utvalda enheter inom NRM sedan 2011, dock i separata databaser och olika versioner. 


2010 påbörjades även diskussioner om ett internationellt DINA-konsortium efter att två museer i 
Danmark utryckte intresse att ingå i DINA. Sedan dess har fler internationella institutioner valt att 
ingå i DINA-projektet. Den internationella samverkan formaliserades 2013 genom ett 
Memorandum of Understanding (MoU) som reglerar samverkan mellan de fyra kärnmedlemmar 
och två associerade medlemmar, som idag utgör DINA-INT. 


Sedan arbetet med migrering till Specify inleddes 2010 har ett antal samlingar helt eller delvis 


migrerats till en Specifylösning som en del av DINA-projektet. Värt att notera är samlingar har 
migrerats till olika versioner och separata databaser av Specifysystemet. 


Översikt av migrering av samlingar till Specifylösning 


Paleozoologiska 
databasen (PAL) 


= 
Z Entomologiska 
databasen (Z00) Mineralogisamling (GEO) 
ö Entomologiska GNM övriga 
2 samlingar (GNM) samlingar 
£E 
4 Entomologiska samlingar (Station 
T Linné) 
> 
:O 


Figur 5: Tidslinje över genomförda och pågående migreringar för NRM och DINA-SE 


Migrering av Paleozoologiska databasen vid NRM påbörjades 2012, men avbröts 2013 då 
ledningen på PAL-enheten ansåg att bristerna med datamodellen var för stora. 


Enheten för botanik har migrerat viss mängd data, men då resurser fokuserats på utveckling av 
DINA-web har arbetet pausats. Migrering av resterande samlingar vid Göteborgs naturhistoriska 


museum har påbörjats och förväntas vara klart under 2019. 


Utöver att stötta andra museer med migrering, har DINA-teamet vid NRM även gett viss träning 
och support till användare. Till följd av att användarna inom DINA-ramverket under åren har blivit 
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fler har även förfrågan om utbildning och support ökat. Till följd av detta har s.k. "Super-users” 
utsetts inom varje samling med ansvar att utbilda andra medarbetare. 


Specify version 6 som var den tillgängliga versionen som DINA-projektet arbetade med under 
perioden 2011-2014 saknade en webgränssnitt, vilket var den stora anledningen till att DINA- 
projektet valde att inleda en egenutveckling av ett samlingssystem och därmed använda Specify 
under en övergångsperiod. 


Att notera är att det idag finns en version 7 av Specify med webbfunktionalitet. Vidare finns det 
ett Specifykonsortium med flera museer och dess samlingar som är en högst relevant part att 
samarbeta med i någon form framöver. 


3.4.2 Summering av egenutveckling av DINA-Web 

Sedan 2014 har DINA-projektet och således även NRM fokuserat på att utveckla ett webbaserat 
system som ska ersätta Specify och verka som ett gemensamt samlingshanteringssystem. 
Systemet, som än idag är under utveckling, är mer känt som DINA-Web. Arbetet med 
utvecklingen av DINA-Web hanteras delvis av DINA-INT-grupperingen och av NRM:s styrgrupp för 
DINA-projektet. Graden av koordinering och samsyn på mål och planer upplevs dock otydliga. 


Sedan 2014 har totalt fem moduler skapats som tillsammans utgör DINA-web. Vissa av dessa 
moduler används och andra är tillgängliga som prototyper eller beta-versioner. 


Ingående moduler för DINA-Web lösningen 


1. DINA-Sequences (DNA-arkivet, SegDB) 


5. Mediaservermodul 2. DINA-Collections 


4. Generisk datamodul 3. DINA-Labels 


Figur 6: De fem ingående modulerna som tillsammans utgör DINA-Web idag 


1. DINA-Sequences (DNA-arkivet, SeqDB): DINA-Sequences är utvecklat av Agriculture and 
Agrifood Canada (AAFC) och är den mest mogna av samtliga DINA-moduler. Modulen har 
funktionalitet för biologiska samlingar. Modulen används dock framförallt som system för att 
hantera data och arbetsflöden inom avancerad DNA-sekvensering vid naturhistoriska museer eller 
forskningsinstitut för biologisk mångfald. Supporten för denna typ av applikationer i Specify är 
begränsad trots stor efterfrågan. Vissa komponenter inom DINA-Sequences har utvecklats särskilt 
för att passa NRMs verksamhet (bl.a. stöd för genotypdata och DNA-provslagring vid DNA-labbet 
på NRM). Modulen används sedan 2018 för provtagning i DNA-labbet samt centrum för genetisk 
identifiering vid NRM. I nuläget arbetar AAFC vidare med att integrera DINA-Sequences med 
övriga DINA-moduler, främst DINA-Collections, vilket förväntas vara klart senast 2020. 
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2. DINA Collections (NRM): DINA Collections är en modul som tagits fram av projektteamet på 
NRM och befinner sig just nu i test på enheten för zoologi och har fungerat som pilot i 
utvecklingsarbetet. Modulen är ännu inte integrerad med övriga DINA-moduler och testas bara på 
vissa samlingar. Tanken är att systemet i framtiden ska kunna ersätta ZOOSs befintliga system 
mam2006 som är en databas i Microsoft Access. 

3. DINA Labels: DINA Labels har utvecklats av Museum fär Naturkunde (MfN) och hanterar 
utskrift, etiketter och rapporter. 

4. Generisk datamodul: Den generiska datamodulen som utvecklats av MfN är konstruerad för 
att hantera äldre data. 

5. Mediaservermodul: Modulen har utvecklats av NRM och används sedan 2016 på 
myndigheten. Modulen är integrerad i Naturforskaren men inte andra DINA-komponenter. 


3.4.3 Övrigt utvecklingsarbete inom DINA-projektet 

Utöver DINA-Specify och DINA-Web har även viss utveckling inom samlingshantering skett 

parallellt men med kopplingar till DINA: 

. 2012-2013: Utveckling av inventeringsklient för Svenska Malaisefälleprojektet. Blev 2014 
naturfynd.se. Den nya funktionaliteten gav användarna möjlighet att publicera samlingsdata 
med hjälp av Excel-filer, vilka sedan automatiskt importeras till Specify. 

« 2013: Utveckling av samlingsportalen naturarv.se där en halv miljon objekt från svenska 
samlingar finns tillgängliga. Dessa tillgängliggörs genom två olika protokoll som DINA- 
gruppen på NRM utvecklade. 

e 2013: Utveckling av DNA-sträckkodsportalen DNA-nyckeln. 

ee 2013: Framtagning av lokal instans av MorphBank för att möjliggöra bildhantering i DINA- 
systemet. 


Det finns troligen fler initiativ och resultat från arbetet med DINA-projektet som inte har kommit 
Ramboll till kännedom. Ovan sammanställning har använts för att utvärdera resultatet av arbetet 
samt analyser för rekommendationer för framtida arbete. 


3.5 Insikter av samlingshantering vid Naturhistoriska riksmuseet 


Stor mängd unika samlingshanteringssystem inom NRM 

Samlingshantering sker idag på olika sätt och hanteras av olika (och unika) system inom 
respektive enhet på NRM. Det är mot denna bakgrund som DINA-projektet startades 2009. 
Sammanställningen som Ramboll har gjort av samlingshanteringssystem påvisar att det än idag 
finns flera olika typer av system. Dessutom finns det en betydande mängd objekt som ännu inte 
digitaliserats. 


Varierande arbetssätt och behov av information 

Att notera är att arbetssättet för hur respektive enhet arbetar med samlingarna skiljer sig åt 
vilket ökar utmaningen och komplexiteten vid införandet av ett gemensamt 
samlingshanteringssystem. Även informationen om respektive objekt skiljer sig åt, vilket är 
naturligt då de omfattar olika typer av objekt. Det medför en ökad komplexitet avseende 
hantering av information. Det finns dock en viss grad av gemensam typ av information som berör 
alla objekt inom alla enheter, såsom information om objektets nuvarande placering och 
lånehistorik, som kan standardiseras och därmed förenkla införandet av ett gemensamt 
samlingshanteringssystem. 


DINA-Web är under utveckling sedan 2014 


DINA-Web är sedan 2014 under utveckling. Idag består lösningen av fem moduler som ännu inte 
är fullt integrerade med varandra. Modulen DINA Collections är ute för test på enheten för zoologi 
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och tanken är att systemet så småningom ska kunna ersätta mam2006. Plan för utrullning och 
när systemet skall ”gå live” är oklart eller har inte kommit Ramboll till kännedom. 


Tidigare system som ersatts av Specify planeras ersättas till fördel för DINA-Web 

Ett antal samlingar, både inom NRM och av andra museer, har migrerats till Specify. Dock anses 
detta system (av vissa projektmedlemmar) inte uppfylla krav och önskemål för 
samlingshantering, varvid alla Specifylösningar kommer att ersättas framöver inom ramen för 
nuvarande ambition med DINA-projektet. I närtid kan även noteras att Lund behöver ersätta sitt 
befintliga samlingshanteringssystemet, där Specify är en trolig lösning. Samlingar har migrerats 
till olika versioner och databaser för Specify vilket kan innebära (onödigt) merarbete om 
samlingar skall tillgängliggöras för intressenter utanför NRM, eftersom access då behöver skapas 
till respektive Specifylösning individuellt. 


DINA-projektet har skapat ett starkt svenskt och internationellt nätverk av intressenter 
DINA-projektet har involverat och engagerat flera museer både i Sverige och internationellt. Mot 
bakgrund av ambitionen att skapa ett gemensamt samlingshanteringssystem för fleramuseer är 
detta en viktig beståndsdel som har åstadkommits. Dock ställer det krav på hantering av den 
komplexitet som samverkan med flera olika intressenter (och dess olika krav och förutsättningar) 
innebär och en ökad mängd information samt objekt att hantera. 
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ÖVERGRIPANDE MÅL OCH KRAVBILD 


4.1 Vår uppfattning av målbilden för DINA 

I alla projekt, oavsett storlek och komplexitet är samsyn om en tydlig målbild en viktig 
framgångsfaktor. Trots det noterar Ramboll att en gemensamt överenskommen och 
dokumenterad målbild saknas. På frågan om målbild för projektet ges en delvis likartad målbild 
av tillfrågade parter i projektet. 


Alla tillfrågade är enade om DINA-projektets mål att etablera ett gemensamt 
samlingshanteringssystem. Dock skiljer sig uppfattningen om huruvida DINA-projektet bör 
omfatta arbetssätt eller endast IT-systemutveckling. Vidare råder samsyn avseende möjligheten 
att samarbeta nationellt och internationellt med utbyte av samlingar. Däremot skiljer sig 
uppfattningen om prioriteringen av olika intressenter, exempelvis om NRMs behov skall 
tillgodoses före andra museers. Det förekommer även något olika syn avseende principer och 
metodik för systemutvecklingen. Överlag bör en målbild adressera alla ovan områden för att 
tydliggöra mål, inriktning och principer för genomförandet av projektet. 


4.2 Vår förståelse av kravhantering inom DINA-projektet 

I all typ av IT-utveckling är kravhantering en framgångsfaktor. Dokumentering av tydliga krav 
från användare och andra intressenter som därefter översätts till tekniska krav och funktioner 
ligger till grund för utvecklingen. Vidare behöver krav dokumenteras på ett strukturerat sätt, 
verifieras samt prioriteras i samråd med relevanta intressenter för att säkerställa att 
förväntningarna ligger i linje med den lösning som kommer utvecklas. 


Baserat på intervjuer och dokumentation framgår att en strukturerad metod för kravhantering 
inte använts vilket medfört att hantering och dokumentation kring krav har brustit. Vidare har 
projektet inte kommunicerat och verifierat eventuella behov som har identifierats i någon större 
utsträckning, vilket lett till frustration hos både interna och externa aktörer. 


De nyckelpersoner som arbetat en längre tid i projektet har förståelse för olika intressenters 
behov och krav vilket därmed (i brist på dokumentation) medför att projektet är beroende av 
dessa individer för att förstå de krav som inhämtats av projektet. I dokumenten ”Kartläggning av 
behoven inom samlingshantering” och ”Kartläggning tekniska behov” finns visst underlag för en 
kartläggning av behov för samlingshantering samt tekniska behov. Ytterligare dokument som 
Ramboll tilldelats där krav beskrivs är ”Questions about the future, potential strategies and 
project phases” och ”Databaser på Naturhistoriska riksmuseet” (se appendix för förteckning av 
dokument). Notera att dessa dokument inte är förankrade med övriga intressenter av projektet, 
exempelvis enheterna inom NRM eller medlemmar i DINA-SE gruppen. 


4.3 Övergripande kravbild på framtida systemlösning 

Utifrån intervjuer och dokumentstudier har Ramboll summerat övergripande funktionella och 
tekniska krav för DINA-projektet. Dessa skall inte anses som kompletta eller förankrade, utan ger 
en bild av vilken typ av komplexitet ett samlingshanteringssystem utgör. 


4.3.1 Funktionella krav 


Utifrån intervjuer och dokumentstudier har Ramboll identifierat ett antal funktionella krav för ett 
gemensamt samlingshanteringssystem som kan grupperas i sju olika områden. 
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Figur 7: Summering av funktionella krav utifrån dokumentstudier och intervjuer 


Notera att områdena i summeringen nedan inte är prioriterade eller rangordnade utan skall ses 
som en sammanställning av krav. 


1. Taxonomi och informationshantering hos objekt: Behov att spara information, data samt 
bilder och filmer om respektive objekt. Information kan relateras till objektet, dess historik, 
placering m.m. Typen av information skiljer sig åt beroende på vilken typ av samling som 
objektet härrör från. 

2. Lånehantering: Behov att kunna registrera, söka och följa upp lån av objekt mellan olika 
museer och andra aktörer. Vidare finns intresse av att kunna se historik för utlåning av objektet 
samt vilken utställning den varit del av. 

3. Publicering av information: Behov att publicera allt eller delar av information och bilder om 
respektive objekt till olika användargrupper. Beroende på användare kan en mer eller mindre 
mängd information göras tillgänglig. Information skall kunna göras tillgänglig via tilldelad tillgång 
eller publikt, d.v.s. tillgänglig för allmänheten. 

4. Sökning av information: Behov av att söka efter information, bilder och data om respektive 
objekt. Synonymer till sökord har efterfrågats av vissa intressenter där objekt eller sökord kan ha 
olika benämningar. 

5. Import och införande av nya objekt: Behov av att lägga till, uppdatera eller importera 
information och bilder om ett eller flera objekt från olika datakällor. Därmed stöds en effektiv 
hantering av utveckling och underhåll av samlingarna. 

6. Utskriftshantering: Behov av att skriva ut etiketter och information om ett eller flera objekt 
med olika mängd information och i olika format. Därmed stöds arbetet med utställningar och 
spridning av information om objekt i samlingarna. 

7. Rapporter och statistik: Funktion för att sammanställa statistik över samlingar och olika 
typer av objekt samt användningsgrad och sökningar i system. Därmed stöds möjligheten att följa 
upp användning och dimensionering av infrastrukturen mm. 


4.3.2 Tekniska krav 


Utifrån intervjuer och dokumentstudier har Ramboll identifierat ett antal tekniska krav för ett 
gemensamt samlingshanteringssystem som kan grupperas i 11 olika områden. 


13/51 


Ramboll —- Projektutvärdering av DINA-projektet 


4. Publicering 


1. Informations- 
hantering 


8. Säkerhets- 
kopiering 


5. Mobila 
enheter 


6. Sökbarhet 


nd 


9. Användar- 
behörighet 


10. Externa 
länkar 


standard API 


Figur 8: Summering av tekniska krav utifrån dokumentstudier och intervjuer 


1. Informationshantering: Stödja informationshantering vid olika typer av samlingar med 
delvis unik typ av information. 

2. Import av data: Import av mindre eller större mängd data. 

3. Datahantering: Hantera data i olika format såsom video, foto och text. Krav på filer upp emot 
200 mb har noterats, men behöver verifieras. 

4. Publicering och konsumtion: Publicera och möjliggöra konsumtion av data från interna såväl 
externa källor. 

5. Mobila enheter: Delmängd av information tillgänglig via mobila enheter. 

6. Sökbarhet: Sökbarhet på specifika ord och begrepp såsom fraser i löpande text. Även 
kombinationer av ord och begrepp. 

7. Språkstöd: Stöd för att spara och presentera information på flera olika språk. 

8. Säkerhetskopiering: Lösning skall kunna hantera säkerhetskopiering, både lokalt och 
centralt. Framförallt vid import av stora mängder information skall användare kunna 
säkerhetskopiera innan import sker. 

9. Användarbehörighet: Behörighet per typ av användare/roll. System skall kunna ge tillgång 
till olika typer av användare eller roller som har olika behörighet att ändra, söka och lägga till 
objekt. 

10. Externa länkar: Lösning skall kunna hänvisa till andra källor och (när möjligt) kunna förse 
användare med länkar som ger enkel access till andra källor. 

11. Stöd för standard-API: Lösning ska stödja standard-API (exempelvis SOAP eller REST) för 
publicering av information till externa källor. 


Prioritering av krav och funktionalitet via MVP 

DINA-projektet har gjort en ansats till att prioritera funktionalitet i en första version av utvalda 
moduler för DINA Web. Prioriterade funktionaliteter och krav utgör en Minimum Viable Product 
(MVP eller Minsta livskraftiga produkt) och är en vedertagen metodik för att utveckla IT-system. 
Syftet är att påvisa värde och nytta av lösning inför vidare utveckling. Exempel på MVP för att 
kunna ersätta mam2006 (ZOO) omnämns i dokument ”Questions about the future, potential 
strategies and project phases” som skrivits av delar av DINA-INT-grupperingen. 
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4.4 Slutsatser avseende målbild och kravhantering 


Målbilden skiljer sig åt mellan viktiga intressenter för projektet 

En tydlig och väl dokumenterad målbild för DINA-projektet saknas vilket försvårar möjligheten att 
skapa samsyn och förankra ett gemensamt mål avseende samlingshantering inom NRM och med 
övriga externa intressenter. Beskrivningar av målbilden för DINA-projektet i intervjuer skiljer sig 
åt avseende omfattning. En av de större skillnaderna är huruvida projektet inkluderar 
standardisering av arbetssätt. En standardisering av arbetssätt och harmonisering avseende bruk 
av viss information skulle medföra mer harmoniserade krav från NRMs olika enheter och därmed 
förenkla framtida utveckling av IT-lösning. 


Det saknas en etablerad och strukturerad metod för kravhantering 

Det har inte applicerats en gemensam och vedertagen metod för kravinsamling i DINA-projektet. 
Det medför att krav som är dokumenterade är utspridda i verksamheten eller finns hos respektive 
projektmedlem som har arbetat med kravställning. Detta försvårar all typ av samarbete med 
andra intressenter framöver samt involvering av nya utvecklingsresurser. Vidare försvårar 
bristande kravinsamling framtida testning av systemet då det inte finns en referens för vad som 
skall testas och vad ett "lyckat" resultat är. 


Krav har inte verifierats och förankrats med interna och externa aktörer 

De krav som har samlats in har inte kommunicerats och därmed inte verifierats av verksamheten. 
Därmed finns en stor risk att verksamheten har andra förväntningar på framtida lösning än vad 
projektgruppen idag utvecklar med DINA-Web. 
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BEDÖMNING OCH ANALYS AV PROJEKTSTYRNING 


5.1 Introduktion till Rambolls metod för projektutvärdering 

För att analysera och bedöma styrning, uppföljning och andra nyckelfaktorer för att driva projekt 
framgångsrikt, har Rambolls metod för projektutvärdering använts. Metoden är baserad på 
Rambolls långa erfarenhet av att leda komplexa IT och verksamhetsutvecklingsprojekt. Metoden 
omfattar de nyckelområden som tillsammans ligger till grund för att driva projektet 
framgångsrikt. Metoden omfattar sju områden som alla innehåller olika delområden, vilket 
presenteras i figuren nedan följt av beskrivningar av respektive nyckelområde. 


Rambolls modell för projektutvärdering 


1. Styrning 


6. Verktyg 2. Projektmetod 


7. Förändrings- 


ledning 


5. Information 3. Kompetens 


NN a” 


Figur 9: Rambolls metod för projektutvärdering som består av sju olika områden 


4. Projektorganisation 


1. Styrning 
Inom nyckelområdet utvärderas hur projektägarskap, styrgruppsarbete, målstyrning samt 
uppföljning av projektet och ekonomin tillämpats i projektet. Exempel på frågeställningar för 
utvärdering är: 
e Finns tydligt ägarskap för projektet? 
e Finns definierade mål? 
e« Används målstyrning och ekonomisk uppföljning? 


2. Projektmetod 
Inom nyckelområdet utvärderas den använda projektmetoden för projektet utifrån för 
projektet relevanta faser så som kravhantering, utveckling, dokumentation m.m. Exempel på 
frågeställningar för utvärdering är: 
e Vilken projektmetod används, och hur? 
. - Hur hanteras arbetet per fas i projektet? 
e Hur förenas projektledning med ett agilt utvecklingsarbete? 
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3. Kompetens 

Inom nyckelområdet utvärderas tillgången till kompetens inom projektledning och för projektet 
relevanta områden så som IT-utveckling och förändringsledning. Exempel på frågeställningar för 
utvärdering är: 

. Vilken kompetens behöver projektet? 

e Vilken kompetens har funnits i projektet? 

« Hur har resurser och kompetens tilldelats i projektet? 


4. Projektorganisation 

Inom nyckelområdet utvärderas projektorganisationen utifrån t.ex. roller och ansvar, 
kunskapsutbyte och samverkan mellan projektet och den ordinarie verksamheten. Exempel på 
frågeställningar är: 

e Vilka roller finns och hur är roller och ansvar definierade? 

« Hur fördelas ansvaret mellan beställarrollen och utföranderollen i organisationen? 

.« Hur samarbetar projektet med den löpande verksamheten? 


5. Information 

Inom nyckelområdet utvärderas hur information och dokumentation hanteras utifrån t.ex. 
datasäkerhet, rutiner kring informationshantering samt informationsdelning med externa och 
interna intressenter. Exempel på frågeställningar för utvärdering är: 

e Vilka rutiner finns för dokumentation och informationshantering? 

e Hur sker informationsdelning med interna och externa intressenter? 

e« Hur säkerställs datasäkerhet? 


6. Verktyg 

Inom nyckelområdet utvärderas användningen av olika typer av verktyg inom projektet så som 
digitala verktyg och verktyg för projektledning, uppföljning och för projektet viktiga områden så 
som IT-utveckling. Exempel på frågeställningar för utvärdering är: 

e Vilka verktyg används för projektledning och projektuppföljning? 

e Vilka verktyg används för IT-utveckling? 


7. Förändringsledning 

Inom nyckelområde förändringsledning utvärderas om tydliga mål och effekter är definierade, om 
målen är väl förankrade i verksamheten samt hur arbetet och dess resultat kommuniceras och 
förankras löpande med verksamheten. Exempel på frågeställningar för utvärdering är: 

« Hur involverar och förankrar DINA-projektet sitt mål och progress med verksamheten? 

. Hur kommunicerar DINA-projektet med interna och externa intressenter? 

« Hur förbereder DINA-projektet verksamheten för resultatet av projektet? 


5.2 Projektutvärdering av DINA-projektet 

DINA-projektet har utifrån Rambolls projektutvärderingsmetod setts över och analyserats. I 
tabellen nedan framgår utvärderingar av respektive nyckelområden utifrån ett antal delområden, 
följt av status och förklaring till bedömning av respektive delområde. 


Förklaring av status vid utvärdering 


Uppfyller de krav och Uppfyller endast delvis de krav Uppfyller inga av de krav som 
behov som ställs på och behov som ställs vilket ställs och därmed försätter 
projektet medför risker för projektet projektet i stor risk 
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Ägarskap finns definierat utifrån att BIO-enheten ansvarar för 
att leda projektet som helhet. Dock anses ägarskapet för 
projektets resultat, dess plan och effekt anses dock vara mer 
otydlig och delvis bristande. Överlag har det saknats 
involvering och ansvarsfördelning på ledningsnivå i den 
omfattning som projektet kräver mot bakgrund av dess mål 
och omfattning. 

Flera styrgrupper finns inom DINA-projektet, hur dessa 
skiljer och förhåller sig till varandra är dock oklart. 
Styrgruppsarbetet har generellt främst hanterat detaljfrågor 
och inte tagit till sig rollen som kravställare och 
kvalitetssäkrare eller följt upp tidplaner, budget och resultat. 
Målstyrning försvåras utifrån avsaknad av en tydlig plan och 
målbild. Även delmål och andra typer av 
projektuppföljningsmål saknas. Det finns ingen långsiktig 
budget kopplat till leveranser i projektet utan medel har 
avsatts för personal under en tidsperiod. 

Nyckelpersoner träffas för att diskutera projektet men det 
saknas ett strukturerat arbetssätt för hur projektet följs upp. 
Dokumentationen kring uppföljning (t.ex. statusrapporter) 
saknas, vilket försvårar möjligheten att följa upp projektet 
historiskt. 

Fåtal nyckelpersoner inom projektet har haft bra insikt kring 
de externa anslag som har givits projektet. Det saknas även 
budget för projektet både utifrån kort och långt perspektiv. I 
brist på tids- och ekonomisk uppföljning av interna resurser 
samt förbrukning av de externa anslagen så saknas överblick 
av förbrukad budget i projektet. 

Projektet har inte applicerat en tydlig och dokumenterad 
projektmetod vilket fått konsekvenser i form av ostrukturerat 
och mindre förankrat arbetssätt. Projektet är av IT-karaktär 
men avsedd projektstyrningsmodell inom NRM (PPS- 
modellen) har ej applicerats inom DINA-projektet. Viss 
struktur har funnits under vissa tidsperioder, som effekt av 
den då tillsatta projektledarens egna initiativ och kompetens. 
Krav för ett gemensamt samlingshanteringssystem finns 
delvis dokumenterade och formulerade i skilda dokument och 
på olika sätt. De krav som har tagits fram har dock inte 
förankrats eller verifierats hos användarna vilket har bidragit 
till frustration i organisationen. I PPS-modellen finns metodik 
för att arbeta med kravhantering beskriven men denna 
används ej. 

Det finns varierande grad av dokumentation under DINASsS 
projekthistorik, troligen beroende på vilka som varit 
involverade i projektet. Särskilt att notera är att det högst 
troligen saknas dokumentation som beskriver utvecklingen 
(koden) av system och informationsmodell vilket försvårar 
framtida introduktion av nya personer. 

IT-enheten sätter upp testmiljöer men är i övrigt begränsat 
involverad. Mot bakgrund av att det saknas överenskomna 
och dokumenterade krav, blir testningen osäker avseende 
vad som testats och hur det skall utvärderas. 

Fram till cirka 2016 användes ingen specifik metod för 
systemutveckling. På senare tid har ett agilt arbetssätt börjat 
appliceras för projektutveckling, dock finns tydliga 
indikationer på mindre erfarenhet och kompetens kring hur 
metoden ska användas. Metoden är ny för NRM och det 
saknas en allmän förståelse för agilt arbetssätt. 

Utifrån arbetssätt och resultat av projektet hitintills bedömer 
Ramboll att det finns en bristande kompetens i att driva och 
leda verksamhets- och IT-projekt som DINA. DINA-projektet 
är ett stort och komplext verksamhets- och IT-projekt, och 
ställer krav på erfarenhet avseende liknande projekt. 


I organisationen finns utvecklingskompetens inom ett 
begränsat antal programmeringsspråk och system. Dock är 
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Projekt- 
organisation 


Information 


Verktyg 


Förändrings- 
ledning 


IT- och 
informations- 
arkitektur 


Kompetens- 
tillförsel 


Roller och ansvar 


Beställarrollen 


Intressent- 
hantering 


IT- och 
informations- 
säkerhet 


Dokument- 
hantering 


Projektlednings- 
verktyg 


Verktyg för IT- 
utveckling 


Projekt- 
uppföljnings- 
verktyg 


det oklart huruvida den kompetensen överensstämmer med 
NRM och DINA-projektets behov på lång sikt. T.ex. kan 
nämnas att projektet valde att arbeta med en agil 
utvecklingsmetod och byta språk till Java Script vilket få 
resurser inom NRM hade kunskap om vid tidpunkt för 
beslutet. 

Syftet med DINA-projektet har inte kommunicerats och 
förankrats i tillräckligt stor utsträckning för att projektet ska 
kunna bedrivas på ett framgångsrikt sätt. Löpande förankring 
och kommunikation med övriga verksamheten har varit 
väldigt begränsad. Bristande fokus och kompetens inom 
förändringsledning har skapat frustration inom 
organisationen. 

Det råder avsaknad av kritiska roller och kompetenser 
avseende IT och informationsarkitektur. Samtidigt saknar IT- 
enheten den kompetensen samt saknar riktlinjer, policy och 
arbetssätt avseende frågor som berör arkitektur inom IT. 
Resurser har vid behov kontinuerligt tilldelats projektet. Dock 
har kritiska kompetenser saknats (eller ej tillsatts). Behov av 
kompetens har tillgodosetts primärt av interna resurser med 
ambitionen att utveckla kompetens istället för att tillsätta 
kritiska kompetenser via externa resurser. Därmed finns en 
stor begränsning av resurser för projektets olika krav. 
Ansvarsfördelningen mellan projekt och verksamhet är 
otydlig men även mellan olika roller i projektorganisationen 
så som styrgrupp, projektledare, projektmedarbetare m.m. 
IT-enheten har haft en begränsad roll trots att projektet till 
stor del består av IT-utveckling. 

Genom projektets gång har det funnits olika typer av 
"beställare" som hanterats var för sig; DINA-INT, 
Artdatabanken, överintendenten, verksamheten m.fl. 
Beställares och övriga intressenters krav och önskemål på 
DINA har ej dokumenterats eller följts upp på ett strukturerat 
sätt. 

Grupper med olika intressenter har satts upp vilket fungerar 
bra via löpande avstämningar. Roller och beroenden mellan 
dessa grupper är dock otydliga. 

Det finns idag ingen policy eller riktlinjer för 
informationssäkerhet, utan endast instruktioner för 
behörighetsstyrning och rollfördelning. Det finns 
gemensamma lagringsutrymmen som skapas och hanteras 
på beställning av NRM. Rutinen medför att en ägare utses 
som styr vem som ska ha tillgång till de olika mapparna. 
DINA-projektet saknar därmed riktlinjer att förhålla sig till för 
att säkerställa en god IT- och informationssäkerhet. Som 
exempel kan nämnas att krav baserade på GDPR-regler inte 
behandlats i projektet. 

Det finns gemensamma ytor för att spara dokumentation. 
Dokumentationen sträcker sig från projektets start 2008 till 
idag. Oklart huruvida all dokumentation finns tillgänglig på 
gemensam yta. 

Tillgången till verktyg för projektledning är begränsad. 
Istället har generella verktyg så som Office-paketet använts 
under projektets gång. 

NRM har testmiljöer som kan användas och har använts inom 
DINA-projektet. Det finns även generella verktyg för IT- 
utveckling och dessa har använts genomgående. 
Tidrapporteringssystem finns och har använts under större 
delen av projektet. NRM har även möjlighet att följa upp 
projektet ekonomiskt baserat på nedlagd tid, inköp och 
externt inhyrda resurser. Det är oklart huruvida all tid 
rapporterats av verksamheten för de projektnummer som 
berör DINA. 


Tabell 1: Analys och utvärdering av DINA-projektet utifrån Rambolls projektutvärderingsmetod 


19/51 


Ramboll - Projektutvärdering av DINA-projektet 


DINA-projektet har endast fokuserat på IT-utveckling 

Arbetet och omfattningen av arbetet med DINA-projektet har endast fokuserat på IT-utveckling. 
Få, om några, aktiviteter har ägt rum med fokus på att anpassa eller förändra arbetssätt eller 
bruk av information för samlingshantering. Ett oförändrat och därmed individuellt arbetssätt och 
bruk av information ökar komplexiteten på utveckling av ett samlingshanteringssystem avsevärt 
och därmed risken för förseningar och ökade kostnader. 


5.3 Slutsatser av projektutvärdering av DINA-projektet 


Bristande kommunikation med verksamheten och avsaknad av förändringsledning 
DINA-projektet har överlag bristande kommunikation och involvering av verksamheten. Endast 
kravinsamling har skett i samarbete med enheterna, men någon återkoppling har ej skett 
alternativt varit väldigt begränsad. Mål, ambition, plan och framtida resurskrav mellan projektet 
och verksamheten har ej heller kommunicerats eller förankrats nämnvärt vilket medfört att delar 
av organisationen inom NRM är frustrerade och negativt inställda till DINA-projektet. Framtida 
projekt, oavsett inriktning, måste säkerställa att förändringsledning och kommunikation med 
verksamheten är en naturlig del i ledningen av projektet. 


DINA-projektet bör anses som ett verksamhetsutvecklingsprojekt, ej enbart IT- 
utveckling 

Ambitionen att utveckla ett gemensamt IT-system för en organisation med skilda arbetssätt och 
nyttjande av information är oerhört komplext och svårt. Istället bör DINA-projektet inkludera en 
arbetsström som fokuserar på att harmonisera arbetssätt och bruk av viss gemensam 
information. Detta arbete skulle förenkla och effektivisera framtida IT-utveckling avsevärt. 


Otydlig och bristande projektstyrning 

Målsättning, delmål och tydliga rutiner för uppföljning av mål saknas eller har ej utförts enligt 
gängse praxis. Arbetet i befintliga styrgrupper har varit fokuserad på detaljer och formuleringar, 
ej ledning och styrning av projektet. Därmed anses det finnas brister i styrning och uppföljning av 
projektet. 


En lämplig projektmetod har inte tillämpats och roller är otydliga 

Trots att DINA-projektet är ett IT- och verksamhetsutvecklingsprojekt har en ändamålsenlig 
projektmetod inte tillämpats. De olika rollerna i projektorganisationen som exempelvis styrgrupp, 
projektledare, projektmedarbetare, beställare m.m. är inte tydligt definierade i förhållande till 
varandra. IT-enheten har dessutom haft en begränsad roll trots att projektet till stor del består av 
IT-utveckling. PPS modellen som är en gängse metod med roll och ansvarsfördelning finns 
tillgänglig inom NRM, men den har ej applicerats. 


Det saknas kritisk kompetens inom projektledning och IT-utveckling 

Det saknas kritisk kompetens inom framförallt projektledning, förändringsledning och 
informations- och IT-arkitektur för att kunna driva och utforma projektet utifrån målbilden. 
Resurstillsättning via enbart interna resurser har begränsat möjligheten att tillföra kritisk 
kompetens till projektet. 


Det saknas viktiga policys och riktlinjer för IT-utveckling 

Det saknas idag aktuella och uppdaterade riktlinjer kring IT-säkerhet och utveckling. Det finns 
inte heller någon övergripande, gemensam syn på hur IT-säkerheten skall säkerställas inom 
DINA-projektet. Ett stort komplext system likt DINA med externa gränssnitt ställer också krav på 
integration och arkitektur, för vilket det saknas riktlinjer för projektet att förhålla sig till. 
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KOSTNADSANALYS OCH EKONOMISTYRNING 


6.1 Iakttagelser avseende kostnadsuppföljning och ekonomistyrning 
Intervjuer med nyckelpersoner från DINA-projektet samt översyn av dokument och data ligger till 
grund för analys av ekonomisk styrning och uppföljning. 


Det saknas en långsiktig budget för DINA-projektet 

Budget för kostnader för olika moment och leveranser av projektet och IT-utveckling saknas. 
Därmed försvåras all typ av ekonomisk uppföljning. Bidrag har sökts från externa aktörer men 
kopplingen mellan de ekonomiska medlen och en plan för utvecklingen av DINA-Web saknas. Det 
finns indikationer på att ansökningarna av de ekonomiska medlen (och dess följdkrav) styr 
utvecklingen av DINA-projektet snarare än verksamhetens krav och behov. Ett exempel på detta 
är bidrag från EU BON som ställde krav på öppen källkod (Open Source) vilket inte nödvändigtvis 
är det bästa vägvalet för NRM och medlemmar i DINA-SE och DINA-INT. 


Bristande ekonomisk uppföljning och kostnadskontroll 

Mot bakgrund av att en regelrätt budget kopplat till mål och delmål i DINA-projektet saknas, blir 
den ekonomiska uppföljningen svår. Styrgruppen för DINA har ingen eller väldigt begränsad insikt 
i det ekonomiska läget och få om några ekonomiska nyckeltal följs upp. Tidrapportering sker på 
olika ställen (projektnummer) varvid total sammanställning av ekonomin ej har utförts 
regelbundet. 


Oklarheter för hur investeringar kan användas för avskrivningar 

Utvecklingen av IT-system kan delvis redovisas som en investering i tillgångar (CAPEX) och kan 
därmed skrivas av över en längre tid vilket kan vara fördelaktigt från ett redovisningsperspektiv. 
Givet vissa förutsättningar ska kostnader för egenutveckling av IT-program tas upp och redovisas 
som en immateriell anläggningstillgång. I projektet har konsultkostnader hanterats utifrån en 
bedömning av att de utgör investeringskostnader inom en anläggningstillgång - och har därför 
inte redovisats mot anslaget. Utifrån detta bör museet lämpligen utreda närmare om - och i så fall 
i vilken utsträckning - delar av personaltiden också ska redovisas som investering. 


6.2 Översikt av nedlagd tid i DINA-projektet 

Tidsrapportering har använts av involverade personer i projektet. Dock är det oklart om all tid har 
rapporterats eftersom t.ex. IT-enheten har uppgett att de inte tidrapporterat någon tid trots att 
de varit involverade i projektet. Ramboll kan därmed inte garantera att tidssammanställningen 
och kostnaderna är kompletta. Dock anser Ramboll att större majoriteten av nedlagd tid och 
kostnader finns redovisade nedan. 


DINA-projektet har förbrukat över 43 000 timmar 


Den totala tiden för de fem DINA-relaterade projektnumren som registrerats i ekonomisystemet 
är närmare 43 000 timmar, d.v.s. cirka 29 ”manår” (baserat på 1500 arbetstimmar per år). 
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Projektnummer Rapporterad tid från projektmedlemmar och verksamheten 


440688 9 360 h 
440834 6 923 h 
440905 152 h 
440923 487 h 
450063 26 270 h 
SUMMA 43 191 h 


Tabell 2: Summering nedlagd tid per projekt samt total tid sedan 201201 


Källa: Utdrag ur Naturhistoriska riksmuseets ekonomisystem för projekt med projektnummer 450063, 
440688,440834,440905, 440923 


I ekonomisystemet har tre typer av aktiviteter särredovisats: projektledning, utveckling och 
migrering, varav största andelen nedlagd tid har skett för migrering. 


Fördelning av nedlagd tid i DINA-projektet 


HB Projektledning 


H Utveckling (anställd personal) 

51” 

mu Migreringsförberedelser och 
migrering 


Figur 10: Uppskattad tidfördelning baserad på tillgängliga data i ekonomisystemet 


Källa: Utdrag ur Naturhistoriska riksmuseets ekonomisystem för projekt med projektnummer 450063, 440688, 
440834,440905, 440923 


Notera att ovan är uppskattning då vissa antaganden har använts p.g.a. mindre begränsningar i 
underlaget. 


6.3 Ekonomisk översyn av DINA-projektet 

Finansiering av DINA-projektet har skett genom anslag från Regeringen, lån från 
Riksgäldskontoret samt bidrag från Sveriges Lantbruksuniversitet (SLU), EU BON (European 
Biodiversity Observation Network) och Synthesis+ (European Commission). 


Samtliga av utredningen kända intäkter redovisas i tabellen nedan utifrån typ av intäkt, aktör, 
period och summa. 
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Typ av intäkt Förklaring Period Summa 
Anslag Anslag från Regeringen 201201 - 201812 7 477 648 
Lån från Riksgäldskontoret” 201210 - 201905 4 999 479 
Bidrag Bidrag via SLU (Artdatabanken) 201101 - 202012 11 200 000 
EU BONX> 201201 - 201711 1 200 000 
Synthesys+X>X>+ 201902 - 202301 1 300 000 
Summa DINA-IRIS 201201 - 201905 26 177 127 


Tabell 3: Intäkter och kostnader under perioden 2012-01 t.o.m. 2019-05 


Källa: Utdrag ur Naturhistoriska riksmuseets ekonomisystem för projekt med projektnummer 450063, 
440688,440834,440905, 440923. Siffrorna är ungefärliga och avrundande. 

+ Konsultkostnader enligt information per juni 2019. Ytterligare kostnader kan ha tillkommit efter detta datum 
”" Kostnader för 18 personalmånader 2012-01 - 2017-11 

”"" Kostnader för 20 personalmånader för perioden 2019-02 - 2023-01 


Av de totalt 26,2 mkr har 4890 kommit via anslag och 5296 via bidrag från externa parter. 


Att notera är att de närmare fem miljoner kronor som refereras till som lån från Riksgäldskontoret 
avser kostnad för inhyrda konsulter, för vilka avskrivning och amortering kan påbörjas när 
systemet tas i drift. Om projektet skulle avslutas måste hela beloppet betalas tillbaka direkt, 
vilket därmed påverkar budgeten 2020 för NRM. 


6.4 Slutsatser av kostnads- och ekonomistyrningsanalysen 


Kostnaden för DINA-projektet uppgår till 26,2 mkr 

Under perioden 201201 - 201905 har kostnaden 26,2 mkr investerats i DINA-projektet varav 
cirka hälften kommer via anslag och resterande via bidrag. Bidrag har främst kommit från 
Artdatabanken via ansökningar från DINA-SE-grupperingen. Enligt ingående avtal med 
Artdatabanken har bidragen varit avsedda för samtliga deltagare i DINA-SE och inte enbart NRM. 


Totalt har över 43 000 timmar rapporterats varav majoriteten på migrering 

Sedan 2012 har totalt 43 191 h, vilket motsvarar cirka 29 manår, förbrukats av DINA-projektet. 
Majoriteten av tiden som rapporterats har lagts på planering, förberedelser och genomförande av 
migrering. Detta kan vara en indikation på att en brist på standardiserat arbetssätt och 
informationsanvändning medför en ineffektiv och komplex migrering vilket ökat mängden nedlagd 
tid. 


Det saknas budget och kostnadsuppföljning för projektet 

Det finns brister och avsaknad av en strukturerad och förankrad kostnadskontroll, uppföljning och 
ekonomistyrning inom projektet. Det saknas därmed även en budget kopplad till plan eller 
leveranser. 


Externt stöd finansierat via lån som behöver betalas tillbaka 

Kostnaden för de externa konsulterna om cirka 5 mkr har upptagits som ett lån från 
Riksgäldskontoret. Denna summa kommer att skrivas av över en tidsperiod som för museet har 
inte bedömts understiga 5 år. Om projektet avslutas behöver museet utreda i vilken utsträckning 
hittills uppbokade kostnader behöver återföras mot anslag. Frågan om andra museer inom DINA- 
SE skall vara med att betala av delar av detta lån bör även det utredas. 


De kostnader som kan relateras till utveckling redovisas ej som investeringar 

Den kostnad (tid) som har investerats i utvecklingen av DINA-Web och inköp av Specify kan 
delvis härledas direkt till investering av 'utrustning” (CAPEX) och därmed nyttja redovisningsregler 
för avskrivningar över en längre period. Det rekommenderas att NRM utreder behovet av att 
förtydliga hur de brukar regler för avskrivningar i DINA-projektet. 
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SAMARBETE MED EXTERNA PARTER OCH FINANSIÄRER 


7.1 Översyn av samarbete med externa parter 

Naturhistoriska riksmuseet har genom DINA-projektet samverkat med flera aktörer både 
nationellt (DINA-SE) och internationellt (DINA-INT). Nedan redovisas dessa närmare utifrån vilka 
parter som ingår i samverkan samt eventuella åtaganden eller förväntningar som finns på NRM. 


7.1.1 DINA-SE 

Fokus i det nationella DINA-arbetet (DINA-SE) har varit att samordna samlingar i ett gemensamt 
samlingshanteringssystem. Gruppens arbete finns dokumenterat på en gemensam webbplats. 
Parterna har tillsammans sökt medel från Artdatabanken, senast för migrering från DINA-Specify 
till DINA-Web samt koordinatsättning och taxonomimatchning för perioden 2017-2019 utifrån att 
DINA-Web förväntats vara i full drift 2020. Denna del av samverkan regleras i kontrakt mellan 
Artdatabanken och NRM (DNR 4.1-272-2016). 


Samtliga samverkansparter som ingått i DINA-SE finns presenterade i tabellen nedan samt 
eventuella individuella åtaganden som finns mellan NRM och respektive part. 


Nationella parter (DINA- 


Evolutionsmuseet, 
Uppsala universitet, 
Uppsala 


Biologiska museet, 
Lunds universitet, Lund 


Göteborgs 
naturhistoriska museer, 
Göteborg 


Herbarium GB, 
Göteborgs universitet, 
Göteborg 


Eventuella åtaganden 


Oklart om det finns en önskan / 
förväntan om stöd med migrering 
till DINA-Specify eller om Uppsala 
önskar vänta ytterligare till DINA- 
Web är moget för direkt migrering 
dit. I intervju bekräftade Uppsala 
att de lyssnar in vad andra museer 
gör för att hitta en lösning. 


Assistans med migrering av 
entomologisamlingen 
(individdatabasen) till DINA-Specify 
(Specify 7) är planerad för hösten 
2019. Det finns särskilda medel 
avsatta för detta, och dessa har 
betalats ut direkt till Lunds 
universitet. Ursprungligen 
planerades att migreringen skulle 
göras till DINA-Web, systemet 
kommer antagligen inte vara 
tillräckligt moget. DINA-Specify är 
således ett mer aktuellt alternativ, 
och det underlättar framtida 
migrering till DINA-Web. 


Avsluta migreringen av GNMs 
samlingar till DINA-Specify (Specify 
7). Utbilda användare och ge 
användarstöd fram tills att 
pågående projekt löper ut 
(december 2019). 


Oklart om det finns en önskan / 
förväntan om bistånd med 
migrering till DINA-Specify eller om 
man önskar vänta ytterligare till 


Förväntningar från 
samtliga 


Kortsiktigt förväntas NRM 
utreda om DINA 
Collections är 
ändamålsenlig och 
återkoppla avseende om 
denna uppfyller kraven 
och möjligheten att vara 
ett framtida gemensamt 
samlingshanteringssystem. 
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DINA-Web är moget för direkt 
migrering dit. 


Tabell 4: DINA-SE-parter och dess krav och förväntningar på DINA-projektet 


xKälla för beskrivning av åtagande och förväntningar: Fredrik Ronquist 


7.1.2 Översikt av DINA-INT 

DINA-INT formades 2014 genom ett gemensamt signerat Memorandum of Understanding (MoU) 
som sträcker sig fram till 2020. Gruppen består av tre "kärnparter" och tre stycken "associerade 
parter”. Mellan kärnparterna finns ett konsortieavtal inom utvecklingsarbetet för vilket de 
gemensamt sökt projektmedel för DINA-relaterade projekt. 


Sedan start har NRM haft ordförandeposten i styrgruppen. Utvecklingsarbetet har fram till nyligen 
koordinerats av NRM men togs under våren 2019 över av AAFC. Orsaken var en större 
kanadensisk satsning inom biodata, som löper fram till år 2022. AAFCs DINA-team har därmed 
utökats till sju heltidsmedarbetare vilket är den största arbetsgruppen inom DINA-INT-gruppen. 
DINA-teamet i Tyskland förväntas dock växa till följd av en stor satsning för att modernisera MfN. 
Satsningen beräknas uppgå till totalt 600 m€ varav en del är avsatt för DINA-projektet. 


Fokus i samverkan för DINA-INT har varit IT-utveckling av DINA-Web baserat på ett gemensamt 
beslut 2014. Specify är dock fortfarande ett viktigt system för många av medlemmarna under en 
övergångsperiod. SNM, NfM och RGBE befinner sig i processen av migrering av data till Specify, 
som även AAFC använt sig av under en lång tid. DINA-INT är dock angelägna att skapa 
förutsättningar för en relativt enkel migrering från Specify till DINA-web i framtiden. Utvecklingen 
av DINA-Web har varit mer komplex än vad DINA-INT förväntat sig och leveransen har blivit 
kraftigt försenad. 


Samtliga samverkansparter som ingått i DINA-INT finns presenterade i tabellen nedan, följt av 
eventuella åtaganden som de externa parterna anser att NRM har gentemot dem i framtiden. 


DINA-INT-medlemmar Eventuella åtaganden” 


Agriculture and Agri-Food Canada, 


Ottawa, Kanada LARGE - AN NA 
Förväntningar på NRM är att delta mer aktivt i 


Museer fär Naturkunde, Berlin, de strategiska diskussionerna och delta mer 
Tyskland aktivt i det gemensamma utvecklingsarbetet 

framöver. Under de senaste 18 månaderna har 
Tartu Natural History Museer, utvecklingsteamet på NRM, på egen begäran, 
University of Tartu, Tartu, Estland arbetat i stort sett på egen hand, utan närmare 

interaktion med resten av utvecklarna inom 
Statens Naturhistoriske Museer, DINA-INT. Detta har varit fördelaktigt på kort 
Kebenhavns Universitet, Köpenhamn, sikt men på längre sikt förväntas mer 
Danmark interaktion vara nödvändigt för att 


utvecklingssamarbetet ska bli effektivt. 


Royal Botanic Garden Edinburgh, 
Edinburgh, Storbritannien 


Tabell 5: DINA-INT-parter och dess åtaganden och förväntningar på DINA-projektet 


xKälla för beskrivning av åtagande och förväntningar: Fredrik Ronquist 


Ett nytt Memorandum of Understanding är under utveckling för de kommande fem åren och 
förväntas vara klart och signerat av medlemmarna hösten 2019. Av de fem institutionerna utöver 
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NRM, som är medlemmar i DINA-INT har tre meddelat att de kommer skriva under Memorandum 
of Understanding. Dessa är AAFC, MfN, RBGE. 


7.1.3 Finansiärer av DINA-projektet 
DINA-SE har ansökt om medel för att finansiera DINA-projektet genom bidrag och anslag från ett 
antal olika aktörer. 


Finansiärer Åtaganden och förväntningar 

Artdatabanken, Sveriges Förväntningar sammanfaller till hög grad med 
Lantbruksuniversitet (Svenska förväntningarna från DINA-SE-parter. Finns medel som 
artprojektets museistöd) inte förbrukats. 


EU-BON (European biodiversity Slutrapporterat, inga ytterligare krav och 
observation network), EU förväntningar. 
Framework Programme 7 


Synthesys+, European NRM behöver framför allt ta ansvar för att leda arbetet 

Commission med ELViS, samt delta i de två övriga DINA-relaterade 
uppgifterna (unika identifierare och koordinatsättning). 
Finns medel som inte förbrukats. 


Riksgäldskontoret (Lån) Bekostnad av cirka 5 mkr för externa konsulter 
behöver återbetalas. 


Regeringen (anslag) Har beskrivits i regeringens regleringsbrev för 
respektive år. Dessa anslag har använts för lön av de 
anställda som deltagit i projektet. Inga direkta 
förväntningar finns avseende åtaganden utöver att 
NRM förväntas uppfylla det uppdrag som ges av 
regeringen. 


Tabell 6: Finansiärer och eventuella krav och förväntningar 


Bidrag från Artdatabanken och EU-BON har skett via ansökningar, beslut, kontrakt och 
redovisning av utfört arbete enligt tidigare beslut. 


Det återstår medel från Artdatabanken samt skyldighet att återrapportera utfall av arbetet. Ett 
större arbete återstår med Synthesys+ där NRM åtagits sig att leda och delta. Även här finns 
medel avsatta för arbetet. 


7.2 Slutsatser av samverkan med externa parter och finansiärer 


NRM har en ledande roll i ett stort internationellt nätverk 

NRM har utvecklat och tagit en ledande position i två stora nätverk där alla har samsyn om 
visionen om ett gemensamt samlingshanteringssystem som möjliggör nationell och internationellt 
informationsutbyte. Fokus för det svenska nätverket har varit att samordna samlingar i ett 
gemensamt system. Valet har blivit Specify som system, men inte som långsiktig lösning. Den 
internationella gruppen fokuserar på utveckling av DIN-Web där NRM förväntas delta aktivt i 
arbetet tillsammans med AAFC och MfN framöver. 


Systemutvecklingen inom DINA-INT tilltar 

En stor del utvecklingsarbete har genomförts inom DINA-INT men planerna är kraftigt försenade 
och det är fortfarande oklart hur mycket arbete som återstår innan ett system är tillgängligt som 
uppfyller de basala kraven för samlingshantering. Både AAFC och MfN har eller kommer att 
mobilisera ansenliga resurser i IT-utveckling av DINA-Web. Mot bakgrund av att utvecklingen 
skett separat och i olika moduler samt med otydliga krav ställer det flera frågetecken avseende 
inriktning och koordinering för den framtida utvecklingen. Utifrån NRMs position som kärnpart 
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finns en stor möjlighet att påverka och säkerställa god koordinering av det framtida 
utvecklingsarbetet så att förväntningar uppnås. Dock ställer det stora krav på styrning och 
projektledning. 


Medel och åtaganden som återstår för NRM 

DINA-projektet har till stor del finansierats av externa medel och därmed finns åtaganden om 
framtida leveranser. Baserat på anslag från Artdatabanken återstår arbetet med att vara 
behjälpliga med migrering av data för utvalda museer inom DINA-SE-grupperingen. Det finns ca 
850 tkr kvar, per juni 2019, att nyttja för att slutföra arbetet. Det finns även åtaganden i relation 
till Syntheses+ där NRM förväntas ta ansvar och leda arbetet med bla a ELViS-modulen. Arbetet 
har ej inletts vid denna rapports slutförande, vilket medför att det återstår ca 1,0 mkr kr (19,5 
personmånader) för att slutföra arbetet. 


Oklarheter avseende koordinering och målsättning mellan DINA-SE och DINA-INT 

Båda DINA-SE och DIN-INT drivs av en gemensam vision om informationsutbyte för forskning och 
allmänheten. Dock skiljer sig arbetet åt mellan grupperna; DINA-SE har fokus på migrering till ett 
gemensamt system medan DINA-INT utvecklar ett framtida system. Rambolls uppfattning är att 
DINA-Web anses vara den långsiktiga lösningen även för DINA-SE-medlemmarna, dock är det 
högst tveksamt om dessa medlemmar varit involverade i kravställning eller diskussioner om 
inriktning av den pågående utvecklingen av DINA-Web. Fortsatt arbete utan en gemensam 
samsyn på ambition, omfattning och plan medför stora risker och skulle troligen medföra att 
medlemmar som inte har möjligheten att invänta framtida lösning avbryter samarbetet med 
DINA-projektet och NRM. 
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ANALYS AV METODVAL FÖR SYSTEMUTVECKLING 


8.1 Metod för utredning av systemutveckling 

I syfte att analysera och utreda DINA-projektet hitintills samt ge rekommendationer för framtida 
inriktning, har Ramboll använt sig av en generell metod för utveckling och införande av system. 

Metoden är System Developement Life Cycle (SDLC) och omfattar krav från inledande planering 

till anskaffning (inköp eller utveckling) och avveckling av ett system eller teknisk lösning. 


Metod för analys av vägval för systemutveckling 


SE 


7. Avveckling 1. Planering 
6. Underhåll och 2. Kravhantering och 
support eventuellt inköp 


System Developement Life Cycle (SDLC) 


5. Testning och 3. Design och 
utrullning konfiguration 


4, Utveckling och 
integration 


Figur 11: Metod, System Development Life Cycle, för utveckling och införande av system 


Med stöd av SDLC-metoden kommer genomfört arbete och framtida alternativa vägval att 
analyseras avseende fördelar, nackdelar och risker för egenutveckling samt inköp av system eller 
tjänst för utveckling. 


Beskrivning av krav i respektive steg i SDLC-metoden 

1. Planering: Syftet med planeringsfasen är att kartlägga behov och utmaningar samt definiera 
målbild och övergripande syfte och funktion med den framtida lösningen. Organisationens 
strategiska inriktning och riktlinjer samt resurser, kostnader, tid, fördelar och andra 
föremål/faktorer beaktas i denna fas. Krav som ställs för att kunna genomföra fasen är att 
organisationen ska ha förmågan att skapa en tydlig målbild och definiera behovet utifrån 
vilket den specifika lösningen ska besvara. För att kunna genomföra denna fas behövs ramar i 
form av IT-strategi och planer för hur organisationen ska vidareutveckla sin IT för att stödja 
verksamheten på medel och lång sikt. Fasen ställer även krav på riktlinjer (eller policys) för 
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vilka system skall förhålla sig till (t.ex. IT-säkerhet) och att kompetens finns tillgänglig som 
kan förtydliga och förankra syftet med det specifika systemet som ska utvecklas. 

2. Kravhantering och eventuellt inköp: Syftet med kravhanteringsfasen är att med hjälp av 
framtida användare identifiera, definiera och prioritera krav och önskemål på den framtida IT- 
lösningen. Fasen innefattar också översättning av funktionella krav till tekniska krav och 
specifikationer för vad systemlösningen bör kunna uppfylla. Detta ställer anspråk på att en 
tydlig strukturerad metodik appliceras för att samla in och förankra behovs- och kravanalysen 
med verksamheten. Vid inköp av extern lösning eller tjänst medför det att funktionella och 
tekniska krav ska kunna ligga till grund för en förfrågan och därefter användas som grund för 
utvärdering av externa leverantörers förmåga, erbjudanden och pris. 

3. Design och konfiguration: Syftet med denna fas är att vidareutveckla funktionella krav på 
design och konfiguration av vald teknisk lösning. Det ställer krav på kompetens inom 
informations- och IT-arkitektur för att säkerställa en hållbar och skalbar lösning samt god 
insikt i vald lösning och hur den kan anpassas för att uppfylla funktionella och tekniska krav. 

4. Utveckling och integration: Syftet med fasen är att utveckla vald lösning och integrera 
med andra lösningar för att säkerställa informationsutbyte. Det ställer krav på teknisk 
kompetens inom valda utvecklingsspråk samt gemensamma, väl förankrade rutiner och 
metoder för utveckling och dokumentation av densamma. 

5. Testning och utrullning: Syftet med fasen är att testa och säkerställa att framtagen lösning 
möter de initialt ställda kraven och önskemålen från verksamheten samt att mobilisera och 
implementera lösningen i verksamheten. Detta ställer krav på en tydlig och väl strukturerad 
metod för testning och införande, spetskompetens inom testning och förändringsledning samt 
ett nära samarbete och väl förankrade planer med verksamheten. 

6. Underhåll och support: Syftet med fasen är att underhålla lösningen från ett tekniskt 
perspektiv för att säkerställa kontinuerlig drift samt att ge support till användare för att öka 
användning och lösa potentiella problem. Detta ställer krav på att det finns en teknisk 
kompetens och infrastruktur som möjliggör support, underhåll och drift. Det ställer även krav 
på att det finns en supportfunktion med personal, rutiner, IT-system och styrning som kan 
leverera användar- och teknisk support. 

7. Avveckling: Syftet är att säkerställa att det vid eventuell avveckling av systemet finns 
förutsättningar att extrahera data och information från systemet i ett format som möjliggör 
migrering till framtida nya system och lösningar. Detta ställer även krav på att vald IT-lösning 
har funktionalitet och stödjer ett format som kan hantera den mängd information som är 
relevant samt kompetens (främst IT-arkitekt) som kravställer och testar att funktionalitet för 
framtida avveckling är möjlig. 


8.2 Utvärdering av arbetet med egenutveckling inom DINA-projektet 

Utifrån SDLC-modellen beskrivs och analyseras fördelar, nackdelar och risker som är förenade 
med den hittills inslagna vägen med egenutveckling nedan. Därefter används samma modell för 
att värdera vägval framöver för DINA; egenutveckling eller inköp av extern lösning eller tjänst. 


Analys av arbetet med egenutveckling inom DINA-projektet hittills 

Naturhistoriska riksmuseet fattade 2014 beslut om att utveckla ett eget system för 
samlingshantering (DINA-Web) då Specify inte ansågs uppfylla myndighetens behov. Nedan finns 
en analys, baserat på SDLC-metoden, med fokus på för- och nackdelar samt risker i respektive 
fas som valet har inneburit. 


Steg i SDLC Fördelar NETLCGIIETS Risker 

Planering Planering har ägts och Vid projektets start finns Hög: bristande målbild 
styrts helt internt, tydliga indikationer på att och plan har medfört 
dock i begränsad det har saknats rutiner olika och uppfattningar 
utsträckning. och strukturer för om syfte och 
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Kravhantering 


Design och 
konfiguration 


Utveckling 
och 
integration 


Kravhantering kan 
utföras av egen 
personal vilket medför 
att involverade 
medarbetare har bra 
insikt i verksamhetens 
behov. 


Vidareutveckling av 
funktionella krav på 
design och 
konfiguration av vald 
teknisk lösning har 
skett av projekt- 
teamet som är 
anställda och har bra 
insikt i verksamheten. 
Det finns personer 
inom organisationen 
med kunskap inom 
vissa 
programmeringsspråk 
och tekniker. 
Medarbetare har 
utvecklat bra insikt i 
informationsbehovet i 
verksamheten i 
arbetet med migrering 
vilket är användbart. 
De lösningar som 
hittills tagits fram för 
testning har 
utvecklats internt av 
dem som har bra 
förståelse för 
verksamheterna inom 
NRM. Medarbetare har 
under resans gång 
utvecklat kompetens 
inom utveckling och 
integration vilket har 
varit användbart i 
projektet. 


genomförande IT-projekt 
och utveckling. Således 
har ingen långsiktig plan 
för DINA förankrats i 
organisationen. Det har 
inte heller tagits fram 
någon tydlig målbild för 
den framtida lösningen. 
Uppfattningen om 
målbilden skiljer sig idag 
mellan ledningsgrupp och 
projektet. Vidare saknas 
väl förankrade riktlinjer 
från IT-funktionen att 
förhålla sig till. 
Uppfattning om huruvida 
krav har identifierats och 
dokumenterats samt 
prioriterats skiljer sig 
mellan olika parter inom 
projektet. Vald metod för 
kravhantering har varit 
undermålig. Krav har inte 
verifierats och 
dokumenterats eller 
förankrats. 

Det saknas en tydlig roll 
och kompetens inom 
informations- och IT- 
arkitektur inom 
organisationen. Då 
kompetens i erforderlig 
kapacitet inte köpts in 
externt, är det idag 
oklart vilka riktlinjer som 
använts för att stödja 
skalbarhet och 
integration samt 
säkerhet av lösningen. 


Utveckling har delvis 
utförts i det språk som 
personal besitter i NRM, 
vilket nödvändigtvis inte 
behöver vara det bästa 
för NRM. Låg insikt och 
kompetens inom Agilt 
arbetssätt inom NRM, 
vilket är normen idag för 
IT-utveckling. 
Dokumentation av 
utveckling är bristfällig 
vilket försvårar 
möjligheten att andra 


omfattning mellan olika 
intressenter. Detta gör 
det svårt att nå 'målet” 
med ett enhetligt 
system eftersom planen 
för hur det ska göras 
och målet för systemet 
är otydligt. 


Hög: framtida lösning 
kommer inte motsvara 
verksamhetens 
förväntningar och behov 
(till fullo). Bristen på 
krav medför att 
utvecklingen av 
lösningen ej har ett 
tydligt mål som skall 
uppnås. 


Hög: risken är att 
befintligt arbete inom 
design och 
konfiguration av 
lösningen är baserad på 
mindre bra principer 
och därmed försvårar, 
fördyrar eller rent av 
omöjliggör skalbarhet 
och integration eller 
migrering. Det skall 
tilläggas att brist på 
tydlig målbild och krav 
försvåras detta arbete 
än mer. 


Hög: kunskap om 
system och 
programmeringsspråk 
som finns att tillgå 
internt begränsar 
valmöjligheterna för 
DINA. Bristande 
dokumentation av 
lösning ökar risk att 
redan utvecklade delar 
av t.ex. DINA-Web blir 
svår för andra att förstå 
och vidareutveckla 
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Testning och 
utrullning 


Underhåll och 
support 


Avveckling 


NRMs verksamheter 
har haft kontroll över 
testning och 
testmiljöer. 
Egenutveckling 
medför god insyn och 
transparens i detta 
arbete. 


En egen support ger 
kontroll av resurser 
och prioriteringar. 
Men dagens brist på 
kompetens, 
infrastruktur och 
rutiner mm medför få 
om några fördelar 
med detta. Detta 
främst mot bakgrund 
av att IT-enheten idag 
inte har någon 
funktion för att förse 
NRM eller någon 
annan organisation 
med stöd inom 
underhåll- och 
support. 


Egen utveckling ger 
egen kontroll av 
system och därmed 
möjlighet till framtida 
migrering. 


skall kunna förstå och 
vidareutveckla koden 
(vilket är det viktigaste 
syftet med en Open 
Source metod). Att 
endast nyttja anställda 
begränsar även 
framfarten av 
utvecklingen. 

Testning har utförts med 
bristande eller ingen 
involvering av 
verksamheten 
(användarna). I brist på 
dokumenterade krav och 
"user stories” är det högst 
oklart vad som skall ligga 
till grund för test och hur 
det skall utvärderas och 
bedömas. Oklart 
huruvida kompetens och 
väl beprövade metoder 
för testning finns inom 
NRM. Bristande 
involvering av 
verksamheten medför 
stora risker vid framtida 
utrullning. 

IT förvaltar system i viss 
utsträckning idag men 
har p.g.a. begränsad 
involvering i DINA- 
projektet inte möjlighet 
att förvalta de system 
som tagits fram för 
testning idag. Det är 
oklart hur underhåll och 
support ska ske utifrån 
att systemen har tagits 
fram av enskilda 
medarbetare och inte 
förankrats med den 
centrala IT-enheten. 
Vidare saknas kompetens 
och teknisk förmåga att 
erbjuda en teknisk 
support. 

Högst oklart huruvida 
krav och utveckling av 
DINA Web har tagit 
hänsyn till migrering och 
framtida avveckling. Det 
är högst relevant för 
Specify som är en 
tillfällig lösning. 


(vilket är grunden för 
Open Source). 


Hög: risken är att 
testning ej utförs på ett 
strukturerat sätt och 
därmed att lösning inte 
möter de förväntade 
kraven och önskemålen 
från verksamheten. Det 
medför i sin tur att 
mobilisering och 
framtida 
implementering av 
lösningen i 
verksamheten försvåras 
nämnvärt. 


Hög: risken är hög då 
det helt saknas planer 
eller förmåga inom NRM 
att förse användare 
med såväl användar- 
som teknisk support av 
något slag. 
Samlingshantering är 
kritiskt för NRMs 
verksamhet och därmed 
behövs en robust och 
tillgänglig support för 
alla typer av frågor och 
problem som kan 
uppstå. 


Hög: risken är hög då 
det finns frågetecken 
avseende funktionalitet 
för framtida migrering 
samt bristande 
dokumentation om typ 
av information i 
nuvarande system. 


Tabell 7: För- och nackdelar samt risker med egenutveckling utifrån de sju faserna i SDLC-modellen 
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Överlag är riskerna höga vid egenutveckling av system baserat på den förmåga och erfarenhet 
som NRM besitter samt utfallet av DINA-projektet fram till starten av detta arbetet. 


Utveckling med Open Source ställer krav på styrning och genomförande 

DINA-projektet har valt att utveckla DINA-Web med öppen källkod (Open Source), med 
motiveringen att enklare kunna hitta resurser för vidareutveckling, mindre beroende till ett enskilt 
bolag samt ge andra externa parter (t.ex. museer) möjligheten att vidareutveckla DINA-systemet 
framöver. Utveckling med Open Source är tilltalande, men det ställer samtidigt viktiga krav på 
NRM och övriga involverade parter i DINA-projektet för att lyckas. Förutsättningar för att lyckas 


med Open Source är: 

« En gemensam syn på syfte, målbild och inriktning. 

e« En transparant och kompetent kontrollfunktion som tar ansvar att gå igenom och besluta om 
vilka tillägg och vidareutvecklingar som skall släppas. 

. Tydlig och pedagogisk dokumentation om befintlig kod samt strukturen för lösningen, för att 
andra skall kunna ta del av befintlig kod och kunna vidareutveckla den. 

. En modulär arkitektur av systemlösningen för att möjliggöra tillägg och vidareutveckling av 
enskilda funktioner eller lösningar. 


Vidare ställer en Open Source-lösning höga krav på framtida supportfunktion då den skall kunna 
ge användar- och teknisk support för en lösning som (delvis) inte utvecklats av NRM. Idag finns 
många Open Source-initiativ men väldigt få av större dignitet till följd av komplexiteteten och 
utmaningen med att hålla ihop utvecklingen och göra den individoberoende. Några bra exempel 
att lära sig av är Magento och WordPress. 


8.2.1 Slutsats av analys av egenutveckling av DINA-Web 

NRMs vägval att utveckla DINA-Web via egna resurser och från grunden var ett djärvt och 
utmanande vägval med tanke på avsaknaden av erfarenheter av systemutveckling av den 
storleken. Resultatet av projektet har inte levt upp till förväntningarna vilket därmed ger tydliga 
indikationer på graden av komplexitet och utmaningar med att utveckla ett system med interna 
resurser. 


Otydliga förutsättningarna för att få positiv effekt av Open Source 

Baserat på de intervjuer och dokumentation som utredningen tagit del av, saknas det idag 
beskrivning av rutiner och strukturer för den viktiga kontrollfunktion som skall ta ansvar för att 
granska och godkänna vidareutveckling av DINA-moduler och funktionalitet från andra parter. 
Vidare saknas en gemensam målbild och plan för framtida utveckling av DINA-Web vilket ökar 
risken att vidareutveckling sker i olika riktningar. Det har även noterats att den kod som har 
skrivits hitintills av systemutvecklare inom DINA-projektet har dokumenterats bristfälligt. Detta 
indikerar en stor risk att nya resurser får svårt att förstå befintlig kod vilket försvårar framtida 
vidareutveckling, vilket var det ursprungliga syftet med att nyttja Open Source från början. 


Brist på långsiktig planering och budget 

Överlag är uppfattningen att planeringen har bedrivits utifrån externa medel och anpassats utifrån 
den aktuella projektledarens preferenser vilket medför ett kortsiktigt perspektiv som inte tar 
hänsyn till de eventuella konsekvenser som det kan medföra. Tydliga indikationer på detta är 
främst avsaknaden av långsiktig målbild, utveckling av funktionalitet kopplat till långsiktig plan 
eller hur en framtida lösning skall underhållas och supporteras av NRM (samt bekostnad av 
detsamma). Det är i dagsläget oklart hur DINA-projektet avser att den framtida lösningen ska 
underhållas, finansieras och supportas. IT-enheten inom NRM saknar både uppdraget och 
förmågan att ge support vilket därmed ställer frågan om vilken roll och ansvar NRM skall ha 
avseende förmedlare av ett svenskt och internationellt samlingshanteringssystem. 
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Frånvaro av informations- och IT-arkitektroller 

Egenutveckling av ett komplext system, likt DINA-Web, ökar vikten av att översätta krav och 
behov i design och struktur till informationsmodeller och system (inklusive integration). Frånvaro 
av informations- och IT-arkitekt inom DINA-projektet har högst troligt ökat risken för att den 
lösning som nu utvecklats inom ramen för DINA-Web är komplex, ineffektiv och dyr att 
vidareutveckla när fler samlingar skall migreras till lösningen, samt vid integration mot andra 
system och externa gränssnitt. 


Avsaknad av etablerade rutiner och kritisk kompetens för egenutveckling 
DINA-projektet har inte har använt sig av gängse metoder och processer för IT-utveckling utifrån 
graden av komplexitet för projektet. Vidare finns det en brist på kritiska kompetenser inom 
projektledning, förändringsledning samt arkitektur vilket är kritiska nyckelroller i ett projekt av 
DINAs komplexitet. Därmed saknas det goda förutsättningar idag för att lyckas uppnå ett gott 
resultat med egenutveckling inom DINA-projektet. 


8.3 Utvärdering av framtida vägval för DINA-projektet 

I följande avsnitt beskrivs generella för- och nackdelar med egenutveckling och inköp av system 
eller lösning externt. Därefter följer en analys och slutsats avseende vägval framöver för NRM och 
DINA-projektet. 


8.3.1 För- och nackdelar med egenutveckling och inköp av systemlösning 

Flera myndigheter och organisationer har utvecklat system för egen del eller använt externa 
parter för systemutveckling. Därmed finns flera aktörer med erfarenheter avseende för- och 
nackdelar med respektive vägval vilket har använts nedan. 


Definition av egenutveckling av system 
Vid egenutveckling avses när en organisation utvecklar en teknisk lösning med interna resurser, 
från inledande planering till utveckling, test, utrullning och underhåll samt support. 


Definition av inköp av systemlösning 

Vid inköp av systemlösning köps ett färdigutvecklat, standardiserat system som finns på 
marknaden. Systemet ägs och förvaltas av utvecklaren som också tillhandahåller support. System 
av denna typ innehåller en del standardiserade funktioner som enkelt kan anpassas 
(konfigureras) medan andra, mer specifika anpassningar, behöver utvecklas specifikt för "kunden". 


Definition av inköp av tjänst för utveckling 

Inköp av tjänst för utveckling innebär att man köper in externa resurser (kompetenser) i form av 
systemutvecklare, projektledare, arkitekter mm för att utveckla ett eget system. Ansvaret för att 
förvalta systemet är ytterst beställaren, men support och förvaltning kan antingen ske internt 
(kräver upplärning eller rekrytering) eller köpas av extern part. Detta alternativ kan kombinera 
interna resurser från beställaren med externa inhyrda resurser för vissa specifika roller eller väl 
avgränsade uppgifter. 


Generella för- och nackdelar med egenutveckling och inköp av systemlösning 


I tabellen nedan presenteras generella för- och nackdelar med egenutveckling, inköp av lösning 
samt inköp av tjänst. 
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Inköp av lösning Inköp av tjänst 


genutveckling 


För- e Total kontroll och ägarskap =» Har etablerade e Till stor del samma som 
delar över utveckling, metoder och struktur inköp av färdigt 
funktionalitet och kod. för hela utvecklings- system, men erbjuder 
e Mjukvaran och processen. möjligheten till en långt 
funktionaliteterna möter de Överlag minskade mer anpassad lösning. 
exakta behoven. utvecklingskostnader = Utvecklaren har 
e Du kan bli en föregångare för de gedigen erfarenhet 
för andra intressenter om standardiserade inom systemutveckling 
ett liknande system inte funktionerna. vilket kan snabba upp 
finns på marknaden. Färdigt system (mer processen (jämfört med 
eller mindre) egenutveckling). 
påskyndar . Beställaren äger 
implementering. systemet och den 
Minskad risk för externa aktören 
beställaren genom att utvecklar mot krav och 
styra (och betala) mål från beställaren. 
mot kravuppfyllnad. 
Experter inom 
support och underhåll 
finns tillgängliga. 
Nack- . Egenutveckling är nästan Utvecklaren har « Samma argument som 
delar alltid förknippat med höga kontroll och ägarskap inköpt system. 


Tabell 8: Generella för- och nackdelar egenutveckling och inköp av systemlösning 


kostnader. Få 
organisationer utvecklar 
idag helt egna system för 
sin kärnverksamhet. Det 
finns få goda exempel, 
däremot finns det gott om 
exempel på misslyckade 
projekt med överskriden 
tidplan och budget”. 
Tidskrävande vid brist på 
interna kritiska resurser. 
Support och underhåll av 
ett egenutvecklat system 
måste tas i beaktning - 
finns erfarenhet och 
förmåga internt? 

Svårt (och dyrt) att 
vidareutveckla system om 
intern kompetens lämnar. 
Egenutveckling ställer krav 
på tydliga ramar för 
organisation, IT-utveckling 
m.m. 

Typiskt sett har 
egenutvecklade system en 
lägre funktionalitet än 
inköpta. 


över framtida 
utveckling av 
systemet, 
funktionalitet och kod 
Funktionaliteten kan 
vara begränsad och 
möter kanske inte 
alla verksamhetens 
behov. 
Vidareutveckling av 
inköpt lösning kan 
vara dyr och 
försvårar framtida 
uppgradering (vilket 
ökar kostnaden 
ytterligare). 
Användare måste 
förlita sig på att 
extern aktör ger 
support och 
underhåll. 


x https://www.kontract.se/blogg/forandringsledning/fem-vanliga-fallgropar-i-it-projekt/ 


e Risk att skapa ett 


beroende till en extern 
aktör om inte system 
utvecklas på ett sätt 
som möjliggör 
vidareutveckling av 
annan part. 


Genomgången av för- och nackdelar påvisar utmaningarna, riskerna och komplexiteten med 
egenutveckling jämfört med inköp av system eller lösning. Riskerna och komplexiteten ökar i 
relation till storlek och omfattning av systemet eller lösningen som avses utvecklas. 
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8.4 Utvärdering av vägval utifrån Naturhistoriska riksmuseets förutsättningar 
Utvärderingen av vägval framöver för DINA-projektet är en utmanande uppgift. Analysen för 
framtida val är uppdelad i två steg: för- och nackdelar med vägval samt en slutlig analys av 
vägval där samtliga förutsättningar tas i beaktan. 


Summering av för- och nackdelar mellan egenutveckling och inköp 
Nedan redovisas en summering av för- och nackdelar med egenutveckling samt inköp av system 
och tjänst utifrån krav från SDLC-modellen. Den fullständiga analysen återfinns i Appendix A. 


.« Steg 1 - 2: Planering, kravhantering och (eventuellt) inköp av tjänst eller system: 
Fördelaktigt att detta arbete drive eller leds med stark involvering av NRM. Dock har DINA- 
projektet påvisat en stor brist i rutiner, kompetens och styrning avseende dessa två steg. 

« — Steg 3 - 5: Design, utveckling och test: Dessa steg ställer stora krav på kompetens inom 
arkitektur och utveckling, vilket påvisats saknas inom NRM. Det är därmed fördelaktigt att ta 
hjälp externt med resurser eller vid inköp av lösning. 

« — Steg 6: Support och underhåll: Det finns kompetens för underhåll inom NRM, dock saknas 
helt förmågan att ge support. Därmed finns en stor fördel med att använda extern tjänst eller 
inköp av system då denna tjänst kan utformas och inhandlas efter att en lösning 
implementerats. 

. Steg 7: Avveckling: Det är fördelaktigt att resurser inom NRM jobbat med migrering vilket 
därmed säkerställer goda insikter i datamodellen. Dock är risken hög med tanke på att 
dokumentation är enligt utsago bristfällig och därmed blir NRM beroende av att dessa resurser 
finns kvar inom organisationen. 


Kostnaderna för egenutveckling jämfört med inköp är svåra att värdera utan faktiska exempel att 
utgå ifrån. Som referens finns dock nedlagd kostnad för DINA-projektet och dess resultat vilket 
ger fördel för inköp av system eller tjänst. 


8.4.1 Summerande analys av framtida vägval för DINA-projektet 
Utifrån best-practice, NRMs förutsättningar och vägval hittills görs i tabellen nedan en summering 
av respektive vägvals fördelaktighet utifrån de olika faserna i SDLC. 


Förklaring av status vid utvärdering 
Mindre eller låg risk där Betydande risker och Hög risk och troligen ökade 
slutlig leverans uppfyller överdragen budget samt kostnad samt högst troligt ett 
krav och önskemål avvikelser i förväntat resultat ej tillfredsställande resultat 


Steg i SDLC Egen- Inköp av Inköp av Kommentar 
utveckling lösning tjänst 
1. Planering Inköp av tjänst anses mest 
fördelaktigt eftersom NRM anses 
behöva stöd för att ta fram en 


tydlig målbild och plan för den 
framtida lösningen. 
Förutsättningarna är i alla tre fall 


utmanande med tanke på IT- 
funktionens mindre roll, men kan 
bryggas tillfälligt om bra expertis 
och vedertagna metoder används. 
2. Krav och Inköp av system eller tjänst anses 
eventuellt mest fördelaktigt då struktur och 
inköp metod för kravhantering inom NRM 
saknas. Fördelaktigt om annan än 
systemleverantör samlar in 
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3. Design och 
konfiguration 


4. Utveckling 
och 
integration 


5. Testning och 
utrullning 


6. Underhåll och 
support 


7. Avveckling 


övergripande krav och stöd vid 
upphandling för att säkerställa 
oberoende rådgivning. Dock 
behöver NRM vara väl involverad 
för att identifiera och prioritera 
krav vilket kan vara en utmaning 
utifrån bristande erfarenhet av 
samverkan mellan enheterna i 
liknande arbetsuppgifter. Vid inköp 
ställer det höga krav på 
inköpsförmåga hos NRM för att 
värdera olika externa lösningar 
eller företag. 

Inköp av system eller tjänst anses 
mest fördelaktigt då kompetens för 
informations- och IT-arkitekt 
saknas inom NRM idag. Med hjälp 
av externt stöd kan vedertagna 
modeller, skalbar lösning och väl 
etablerade teknik för integration 
mm bli en del av i lösningen. 
Kraven kommer att vara 
avgörande för vilket alternativ som 
är mest lämpligt för NRM. Dock 
tyder NRMs bristande erfarenhet 
inom agil utveckling samt 
dokumentation vilka risker 
egenutveckling kan medföra. 
Inköp av tjänst ger större 
valmöjligheter och flexibilitet i 
jämförelse med inköp av lösning. 
Inköp av system eller tjänst anses 
mest fördelaktigt då kompetens 
och förutsättningar för test och 
utrullning inte finns i sin helhet. 
Vid inköp av systemlösning eller 
tjänst kan expertis för test och 
utrullning involveras vilket ökar 
sannolikheten till att lösningen 
mottas väl av verksamheten. 
Inköp av system eller tjänst anses 
mest fördelaktigt då IT-enheten 
idag inte har förmågan att leverera 
support och därmed saknar 
förutsättningar för att säkerställa 
drift av en systemlösning av denna 
typ. Kostnaden för egen support 
eller vid inköpt tjänst är högre än 
om kostnaden för support delas 
mellan flera aktörer. 

Utveckling i egen regi eller som 
tjänst medför att beställaren 
(NRM) kan kravställa på 
funktionalitet för migrering och 
avveckling. Med egenutveckling 
och inköpt lösning är det 
leverantören som styr över 
livscykeln för lösningen. 


Tabell 9: Summerande analys av vägval mellan egenutveckling och inköp av lösning eller tjänst 
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Analysen påvisar en övervägande fördel för inköp av tjänst eller lösning, där inköp av tjänst är att 
föredra i de inledande två faserna för att säkerställa oberoende rådgivning vid val av framtida 
lösning. 


8.5 Slutsats av analys för vägval framöver för NRM 


Open Source som utvecklingsmetod bör utvärderas 

Open Source som utvecklingsmetod ställer krav på viktiga kontrollfunktion som ansvarar för att 
granska och godkänna nya samt vidareutveckling av befintliga DINA-moduler och funktionalitet. 
Planerna och målbilden för denna granskande funktion med tillhörande rutiner och kompetens 
bedöms oklar samt är ej dokumenterad och förankrad med berörda parter. Därutöver finns 
frågetecken avseende beskrivande dokumentation av utveckling och migrering inom DINA- 
projektet vilket medför att Ramboll rekommenderar att utvärdera för- och nackdelar med Open 
Source samt utreda vägvalet som en del av framtida arbete. 


Säkerställ att DINA mobiliserar kritisk kompetens innan vidare arbete, oavsett vägval 
DINA-projektet saknar kritisk kompetens inom projektledning, arkitektur (Informations- 
modellering och IT) samt förändringsledning, vilket delvis är den grundläggande orsaken till 
DINA-projektets resultat. Oavsett vägval framöver för DINA-projektet, säkerställ att tillförlitlig 
kompetens inom respektive område finns tillgänglig i projektet oavsett metod för 
kompetenstillförsel. 


Större risker och kostnader förknippad med egenutveckling 

Som analysen påvisar så finns det en del fördelar med egenutveckling, både generellt och utifrån 
Naturhistoriska riksmuseets förutsättningar. Dock i jämförelse med inköp av system eller tjänst är 
riskerna, kostnaderna och andra nackdelar kopplade till egenutveckling högre, både generellt och 
utifrån Naturhistoriska riksmuseets förutsättningar. Analys av andra organisationers erfarenhet 
vid egenutveckling belyser denna slutsats och det idag är sällsynt med helt egenutvecklade 
system utan stöd från externa parter. 


Fördel med inköp av system eller tjänst 

Naturhistoriska riksmuseet har aldrig tidigare genomfört ett liknande projekt av IT-karaktär med 
samma grad av komplexitet (mängd information och funktionalitet) och antal involverade parter 
(nationella som internationella). Det saknas kritisk kompetens och erfarenhet att leda och driva 

ett projekt av denna typen internt, vilket utfallet hitintills av DINA-projektet vittnar om. Därmed 
är inköp av tjänst eller lösning att rekommendera, både från ett risk- och kostnadsperspektiv. 


Brist på tydlig målbild och krav försvårar slutliga rekommendationer för vägval 

För att kunna rekommendera bästa möjliga vägval mellan inköp av färdigt system eller inköp av 
tjänst att utveckla lösning, behöver det finnas en tydlig målbild och väl dokumenterade (och 
prioriterade) krav. I avsaknad av dessa kan inte denna utredning avgöra slutligt vägval avseende 
inköp av system eller inköp av tjänst som bästa metodval framöver. Däremot kan NRM relativt 
effektivt positionera sig för att kunna göra detta vägval förutsatt att information och utvalda 
resurser i DINA-projektet bidrar till ett väl underbyggt underlag för beslut om vägval. Mer om 
detta i kommande kapitel. 
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REKOMMENDATION AVSEENDE BÄSTA VÄGVAL FÖR 
DINA-PROJEKTET 


9.1 Rekommenderat angreppssätt och vägval för DINA-projektet 

Utifrån de brister, utmaningar och slutsatser som presenteras i analysen för denna 
projektgenomlysning, rekommenderar Ramboll att DINA-projektet bör välja endera av inköp av 
system eller tjänst som inriktning för DINA-projektet. Denna utredning är begränsad avseende 
underlag och information om valmöjligheterna mellan inköp av färdigt system eller utveckling av 
lösning, varvid det rekommenderas att ta fram ett grundligt underlag och genomföra en värdering 
av relevanta valmöjligheter inför det slutliga valet av inriktning för utveckling av framtida DINA- 
lösningen. 


Rekommenderat angreppssätt för vidare arbete i DINA-projektet 


&ö 


Målbild för DINA 


Krav- och önskemål 


o 


DB 
TES 


PÅONS 


ko» 


Egenutveckling Extern utveckling 


Beslutspunkt för vägval av DINA-projektet 


Figur 12: Rekommenderat angreppssätt vid vägval för DINA-projektet 


Vidare föreslår Ramboll ett antal principer för det vidare arbetet baserat på utvärderingen av 
DINA-projektet samt tidigare erfarenheter. 


Mobilisera rätt kompetenser inför vidare arbete 

Det är rekommenderat att engagera en erfaren projektledare för DINA-projektet med erfarenhet 
av liknande uppdrag och utmaningar. Längre fram i uppdraget krävs kompetens inom 
informations- och IT-arkitektur, vilket bör mobiliseras i projektet för att säkerställa att struktur 
och design av lösning uppfyller krav på skalbarhet, integration samt framtida krav och utveckling. 
I förslag till projektplan finns kritiska resurser per fas beskrivet. 


Skapa och förankra ett väl genomarbetat underlag för inriktningsval 


Framtida val av inriktning och lösning för samlingshantering bör föregås av att en tydlig målbild 
och prioriterade krav dokumenteras och förankras bland berörda parter (inom och utanför NRM). 
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Genomlysning av DINA har påvisat en otydlig och avvikande syn på målbild för projektet vilket 
medför stora risker vid genomförande. 


En tydlig målbild bör åtminstone svara på: 

. Vad är syftet och ambitionen med DINA? 

e Vilken (mätbar) effekt vill NRM uppnå med ett samlingshanteringssystem? 

. Vilka är användarna och på vilket sätt skall de använda DINA? 

. I vilken prioritering skall projektet bemöta användarnas olika krav? 

. Vad är den övergripande tidsplanen för DINA? 

e Vilka riktlinjer/principer skall projektet och lösningen förhålla sig till? (Exempelvis: stödja 
gemensamt arbetssätt, skalbar lösning, Open Source eller ej o.s.v.). 


Krav och önskemål på lösningen bör i högsta grad identifieras, definieras och prioriteras 
tillsammans med de utvalda och prioriterade användarna. Det rekommenderas att använda 
vedertagna och etablerade rutiner för kravinsamling och dokumentation, som även kan användas 
för framtida test. Exempel är metoden som inkluderar framtagande av ”epics", "user stories” och 
acceptanskriterier som sedan översätts till tekniska krav och design. Anpassa metod och 
detaljgrad av krav efter projektets behov. Värdera och prioritera behov efter dess värdeskapande, 
risk och kostnad för utveckling. 


Funktion eller kompetens inom inköp bör involveras tidigt för att möjliggöra att insamlade behov 
kan ligga till grund för förfrågan för inköp av tjänst att utveckla lösning eller inköp av existerande 
system. 


Utvärdera DINA-Web och Specify som en del av framtida vägval 

Vid utvärdering av externa tjänster eller lösning som vägval för DINA-projektet, bör Specify och 
DINA-Web ingå för att kunna värdera nya alternativ mot redan kända. Dock skall de värderas mot 
samma målbild och kravbild som externa lösningar. Notera att det är jämförelse av den tekniska 
lösningen som främst avses vid jämförelse mellan DINA och Specify mot andra externa 
valmöjligheter. Oavsett vägval behöver NRM komplettera med rätt kompetens för 
projektgenomförande och system-utveckling. Notera även att utvärdering bör även innehålla 
utvärdering av leverantör eller organisation som står bakom respektive alternativ. Denna 
utvärdering bör innehålla framtida planer för utveckling, finansiell styrka, geografisk spridning 
(om DINA skall användas internationellt), förmåga att ge support samt resursers kompetens. 


Harmonisera processer och information som en del av DINA-projektet 

Att utveckla ett samlingshanteringssystem som passar alla individuella enheters behov är ytterst 
svårt och komplext. Därför rekommenderar Ramboll harmonisering av arbetssätt samt bruk av 
gemensam typ av information för att därmed förenkla design och detaljerad kravställning på 
framtida lösning. Utveckling och förändring av processer behöver nödvändigtvis inte genomföras 
innan vägval för utveckling av system, dock bör det färdigställas innan detaljerade krav och 
design av lösning och informationsmodell är avslutat (då detaljerade krav bör baseras på 
arbetssätt och bruk av information). 


Använd PPS som projektmodell och andra gängse metoder för systemutveckling 
Utveckling av en teknisk lösning samt förändring av arbetssätt kräver en etablerad projektmodell, 
likt PPS. Eftersom PPS är vedertagen inom NRM rekommenderas att projektet använder sig av 
denna projektmodell som grund för styrning och genomförande av DINA-projektet, oavsett 
vägval. Vidare rekommenderas att använda beprövade metoder och verktyg för kravinsamling 
och systemutveckling, dock anpassade efter projektets mål, utmaningar och förhållande. 
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9.2 Rekommendationer avseende samverkan med externa parter 

DINA-projektet har sedan start byggt upp ett stort nätverk av internationella och nationella 
aktörer som mer eller mindre varit med i utvecklingsarbetet. Ett framtida vägval måste därmed ta 
dessa i beaktning. Vidare gynnas ansökningar för externa medel om flera aktörer söker 
tillsammans. Det skall dock inte vara den tongivande anledningen för hur NRM bör hantera 
framtida samarbete. Eftersom arbetet och framtida planer skiljer sig åt mellan DINA-SE och 
DINA-INT föreslås olika tillvägagångssätt mellan dessa båda grupper. 


För DINA-SE gruppen: sök stöd och samarbete för NRMs målbild och krav 

Mot bakgrund av den strategiska inriktning som NRM tagit fram (interna behov framför externa) 
föreslås att NRMs interna förankrade målbild, generella krav samt övergripande plan koordineras 
och verifieras med relevanta aktörer (efter att den är förankrad inom NRM). Syftet är att 
säkerställa samsyn avseende målbild samt en rimlig plan och budget för utvecklingen. Därmed 
kan en gruppering med gemensam målbild och plan etableras, vilket underlättar eventuella 
framtida ansökningar om finansiering. 


För DINA-INT-gruppen: utvärdera risker och tidsplan med ett framtida samarbete 
Resurser och vidareutvecklingen av DINA-Web inom DINA-INT-grupperingen ökar, i och med 
resursbidrag från AAFC och MfN. Därmed kommer komplexiteten (ökat antal krav, utveckling i 
olika team med bristande kommunikation och fler involverade parter) öka drastiskt. Därmed 
rekommenderas det att NRM gör en utvärdering av eventuellt vidare aktivt samarbete med DINA- 
INT efter att en målbild och generella krav tagits fram. Utvärdering bör ske utifrån den framtagna 
målbilden och tidsramen som NRM kommit fram till jämfört med de risker, kvalitet av lösning och 
kostnad som det medför att fortsätta egenutveckling av DINA-Web som en del av DINA-INT. 
Notera att denna utvärdering bör ske under 2019 med anledning av förlängningen av det MoU 
som pågår och där fler parter meddelat att de har för avsikt att delta framöver (och räknar med 
NRMs deltagande). 


Hantering av återstående arbete och förväntningar 

Det finns fortfarande medel kvar inom DINA som inte förbrukats och med det tillhörande 
förväntningar och leveranser. Dessa bör hanteras varsamt och troligen fullbordas (utifrån den 
ringa information som Ramboll erhållit). 


Medel för migrering av samlingar för medlemmar av DINA-SE återstår där arbetet med Göteborgs 
naturhistoriska museum pågår och medel finns avsatta för Biologiska museet i Lund. Här 
rekommenderas det att använda sig av senaste version av Specify (förutsatt att datamodell är 
kompatibel inom ramen för budgeten) för att kunna tillgodose en lösning som är fungerande och 
motsvarar majoriteten av de krav som finns. 


Medel från Synthesys+ (European Commission), del av DINA-INTs arbete, återstår och med det 
förväntningar och krav på att NRM tar ansvar för att leda arbetet med ELViS-modulen, samt delta 
i de två övriga DINA-relaterade uppgifterna (unika identifierare och koordinatsättning). Det finns 
medel som inte förbrukats för detta arbete. 


Det lån som upptagits avseende extern konsultation bör adderas i framtida budgetarbete för 
avbetalning på kort eller lång sikt beroende på val av lösning (lån måste betalas tillbaka direkt om 
inte DINA-Web väljs som gemensamt system). 


9.3 Förslag på övergripande plan för genomförande 


Baserat på våra rekommendationer har Ramboll tagit fram ett förslag på övergripande plan för 
målsättning, vägval och genomförande av arbetet. 
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Figur 13: Rekommenderad plan för vidare arbete och genomförande av DINA-projektet 


1. 


Etablera en gemensam målbild och krav 

Skapa en målbild och definiera samt prioritera krav utifrån NRMs behov, samt en 

övergripande tidsplan. Målbilden ska vara i enlighet med den strategiska planen 2019-2022. 

Kommunicera och (om möjligt) verifiera målbild och krav med externa parter för att söka 

partnerskap och därmed medfinansiärer. 

. - Kritisk resurs: projektledare. 

. Tidsplan: cirka 3-4 veckor (för NRM) och cirka 3 veckor med externa parter. 

Värdera alternativ och gör vägval 

Sammanställ underlag (krav, målbild, tidsplan mm) och gör en grundlig värdering av 

relevanta alternativ. Inkludera vidare arbete med DINA-Web samt Specify som alternativ 

tillsammans med inköp av lösning och inköp av tjänst. Som en del av vägvalet bör även NRMs 

framtida relation och förhållande till DINA-INT-grupperingen och andra internationella aktörer 

ingå. 

. - Kritiska resurser: projektledare, inköp. 

. Tidsplan: cirka 2-3 veckor (för underlag) och cirka 4-6 veckor för invänta svar och 
utvärdera alternativ. 

Design av lösning och plan för utveckling 

Vidareutveckla krav och utifrån dessa, designa den tekniska lösningen samt 

informationsmodellen. Säkerställ att ledande principer och riktlinjer (interna såväl som från 

externa parter) efterlevs för att säkerställa integration och informationsutbyte med andra 

samlingshanteringssystem. Baserat på design av lösning, skapa en detaljerad utvecklingsplan 

och mobilisera utvecklingsresurser. 

e Kritiska resurser: projektledare, informationsarkitekt, IT-arkitekt, förändringsledare 
(processer och arbetssätt). 

. Tidsplan: cirka 3-4 veckor för övergripande arbetssätt samt ytterligare 1-2 veckor för 
harmonisera bruk av gemensam information. 

Utveckling och införande 

Teknisk utveckling och införande av ett gemensamt samlingshanteringssystem. Följande steg 

ingår i utvecklingsskedet: 

e Systemutveckling. 

. Test. 

e - Migrering. 

e« Implementering och utrullning. 

e Avveckling av äldre samlingshanteringssystem. 

e Kritiska resurser: projektledare, informationsarkitekt, IT-arkitekt, utvecklingsresurser. 

e Tidsplan: oklart, beroende på vägval av lösning. 


9.4 Rekommenderad metod och organisation för projektgenomförande 
Projektgenomlysningen har påvisat flera brister inom genomförande och projektorganisationen. 
Dessa brister behöver åtgärdas innan DINA-projektet fortsätter i stor skala. Ramboll föreslår att 
följande fem områden adresseras inledningsvis i projektarbetet. 
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Figur 14: Viktiga områden att adressera i det framtida projektet 


« - Projektorganisation: Säkerställ en tydlig organisation med definierade roller och tillhörande 
ansvar. Det inkluderar relationen och beroenden mellan externa aktörer såsom DINA-SE och 
DINA-INT. 

« — Rätt person i projektet: Säkra rätt kompetens för kritiska roller såsom projektledare, 
förändringsledare och arkitekter. 

.« - Projektägarskap: Definiera tydligt ägarskap för projektet och den framtida lösningen samt 
vilka styrmekanismer och mandat det medför. 

« Styrning och Budget: Definiera mål, nyckeltal och budget för arbetet som underlag inför 
uppföljning av ansvariga grupperingar och roller. 

.« - Projektmodell och rutiner: Använd PPS och andra gängse rutiner för kravhantering och IT- 
utveckling. Anpassa modeller och rutiner efter projektets mål, behov och förutsättningar. 


Det återfinns fler områden att utveckla och förbättra, men adressera dessa efter att ovan är 
genomfört och infört till en acceptabel nivå. 


9.5 Risker och framgångsfaktorer 
Utifrån utredningen samt de analyser och slutsatser som presenterats bedömer Ramboll att 
följande risker och framgångsfaktorer finns med DINA-projektet oavsett vägval. 


Identifierade risker 


Nedan är en lista med identifierade och höga risker för framtida DINA-projektet. Denna lista bör 
utvecklas och följas upp löpande framöver. 
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Risker Mitigering av risk 


« Begränsad budget inom NRM =» = Nyttja erfarenheter från extern finansiering av 


DINA. 
. - Kartlägg nya möjligheter att finansiera lösning. 
.« Bristande engagemang för e« - Mobilisera en stark och organisationsöverskridande 
DINA-projektet styrgrupp. 


e - Involvera ledningsgruppen i kommunikation av 
DINA-projektet. 


. Brist på lämplig kompetens e Sök kritisk kompetens externt vid behov 
. Bristande dokumentation av e Säkerställ befintliga resurser dokumenterar lösning 
den befintliga lösningen och kvalitetssäkra dokumentation med extern 
resurs. 
. Bristande relationer med e Motivera väl framtida vägval och erbjud möjlighet 
andra museer för andra att delta i projektet. 


Tabell 10: Identifierade och höga risker för framtida DINA-projektet 


Riskhantering bör vara en naturlig del i projektledningsarbetet och utgöra en del av den 
regelbundna uppföljningen av projektet. 


Identifierade framgångsfaktorer 
«  Mobilisera kritisk kompetens =» Oavsett inriktning behöver projektet relevant 
kompetens och erfarenhet för kritiska roller - detta 
bör säkerställas inför vidare arbete i projektet. 


.« -Ledningsgruppens « Ledningsgruppen är idag involverad i DINA och bör 
engagemang så förbli under hela arbetet för att säkerställa 

prioritering och styrning av arbetet. 

« — Definiera tydliga och väl e Säkerställ att relevant kompetens är involverad och 
förankrade krav vedertagna rutiner och verktyg används. 

. - Harmonisera processer och . Ett system kan omöjligt hantera alla typer av unika 
bruk av information, innan krav utan det måste finnas en grad av samsyn, 
funktioner och detaljerade harmonisering och standardisering av främst 
krav på system etableras arbetssätt men även viss gemensam information för 

att förenkla krav på och utveckling av system. 

e« - Översätt krav till design av . God kravställning säkerställer en design av en 
lösning samt tillhörande plan lösning som uppfyller kortsiktiga och långsiktiga 

mål. 

.« - Involvera och engagera . En lösning är aldrig bättre än nyttjandegraden av 
intressenter löpande dess användare. Involvera och kommunicera därför 


löpande under hela arbetet. Kompetens inom 
förändringsledning är därför kritisk för projektet. 


Tabell 11: Identifierade framgångsfaktorer för framtida DINA-projektet 


Ovanstående framgångsfaktorer ligger som grund till den plan och rekommendationer som 
Ramboll givit ovan. Genomgång och diskussion om övriga framgångsfaktorer är en bra övning att 
inleda uppstarten av DINA-projektet med. 


9.6 Förslag på principer för framtida samlingshanteringssystem 

Baserat på ett antal intervjuer och tidigare erfarenhet av systemutveckling och implementering 
finns nedan ett antal principer och riktlinjer som NRM kan överväga att nyttja som en del av 
framtida målbildsarbete. 
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Principerna avser design och utveckling av system för att säkerställa att NRM utvecklar eller köper 
en lösning som kan nyttjas av olika enheter och även uppfylla framtida krav från olika 
intressenter. 


Skalbar lösning: samlingshanteringslösning bör kravställas och designas utifrån framtida 
dimensionering av datahantering, båda avseende lagring, sökning och integration. På kort sikt 
bör de mest prioriterade kraven uppfyllas i tidigare versioner av lösningen, samtidigt som 
lösningen kan enkelt vidareutvecklas för att uppfylla mindre prioriterade krav. 

Etablera en långsiktig utvecklingsplan: vid framtagning av en gemensam målbild, 
utveckla och bryt ned den till en långsiktig plan för systemutveckling. Därmed kan projektet 
tydligt kommunicera vad som avses utvecklas och när till berörda intressenter av DINA- 
projektet. Vidare säkerställs att utvecklingen av systemet på kort sikt tar hänsyn till och är 
kompatibelt med framtida utveckling. 

Skapa ett modulärt system: system bör utvecklas i moduler där relaterade funktioner finns 
grupperade i en och samma modul. Detta förenklar och snabbar på utveckling och 
vidareutveckling av lösning. 

Använd standard-API för all integration: använd standardiserade API:er (exempelvis 
SOAP eller REST) för all typ av integration, både mellan moduler och med webgränssnitt och 
andra samlingshanteringssystem. 

Utveckla informationsmodell utifrån långsiktiga mål och behov: val av datamodellstyp 
och design av informationsmodell är en kritisk framgångsfaktor då det är kärnan i alla system 
som hanterar information. Därmed är det viktigt att den framtida informationsmodellen är 
designad utifrån långsiktiga behov inom och utom NRM. 

Överväg alternativ till Open Source: krav och förmåga att lyckas dra nytta av de effekter 
som en Open Source-lösning kan ge är utmanande där få organisationer har lyckats uppnå 
dem. Överväg därför andra alternativ och dess fördelar. 


9.7 Övriga iakttagelser och rekommendationer 

Under arbetet med projektgenomlysningen har Ramboll gjort andra iakttagelser som är av vikt att 
lyfta, då de indirekt eller direkt har en påverkan på framtida arbete med DINA-projektet. Listan 
skall ses som en sammanställning utan underliggande prioritering eller värdering. 


Förstärk medarbetares kompetens inom PPS: det finns tydliga indikationer på att få inom 
NRM har kunskap om PPS och hur metoden används. Ramboll rekommenderar således att de 
medarbetare som är involverade i DINA-projektet deltar i utbildning eller annan metod för att 
tillskansa sig erforderlig kunskap om PPS. 

Inför samlad och standardiserad projektuppföljning inom NRM: DINA-projektet är ett 
av flera projekt som drivs inom NRM. Den strategi som NRM tagit fram innehåller flera mindre 
och större initiativ (projekt) som behöver följas upp. Därmed rekommenderas det att NRM 
använder en samlad och standardiserad metod, struktur och funktion för all 
projektuppföljning. En gemensamt applicerad metod i alla projekt kommer att stödja 
ledningsgruppen i uppföljning av initiativ (projekt) och därmed underlätta införande av NRMs 
strategi. 

Applicera ett mer flexibelt synsätt för kompetensförsörjning: under utredningen av 
DINA-projektet framgår att kompetensförsörjningskulturen i stort endast sker via anställning 
trots att behovet inte nödvändigtvis är långsiktigt. Ramboll rekommenderar att framtida 
rekryteringar utgörs av mer noggranna utredningar kring om den aktuella resursen ska 
tillsättas via långsiktig rekrytering eller tillfälligt (via konsult) med hjälp av externa aktörer. 
Förstärk IT-enhetens roll inom IT-projekt och NRM: IT-enheten har spelat liten roll i 
DINA-projektet trots att det är ett ”IT-projekt”. Vidare saknas det "strategier", planer, riktlinjer 
och policys för IT-utveckling och användning generellt vilket föranleder slutsatsen att NRM bör 
se över och förstärka IT-enhetens roll inom organisationen. I en allt mer digital omvärld är IT- 
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enhetens förmåga en kritisk faktor för att NRM skall kunna realisera verksamhetens mål och 
planer. 

. Etablera tydliga riktlinjer för hur bruka CAPEX- och OPEX-kostnader: otydlig hantering 
av investeringar i redovisning ligger till grund till rekommendationen att se över och förtydliga 
användning av avskrivningar samt relatera delar av kostnaderna inom DINA (förslagsvis tid 
och kostnader för ”systemutveckling” till CAPEX och därmed underlag för avskrivningar över 
en längre tid. 
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10. 


APPENDIX A - DETALJERAD UTVÄRDERING AV 
EGENUTVECKLING VS. INKÖP 


I tabellen nedan redovisas den detaljerade jämförelsen mellan egenutveckling och inköp av 
system/lösning. Inköp av system och lösning har i denna analys slagits ihop då det skiljer sig lite 
dem emellan. I analysmetoden har risker och kostnadsperspektivet tagits med för att komplettera 


analysen. 


1. Planering 


2. Kravhantering 
och inköp 


3. Design och 
konfiguration 


4. Utveckling 
och 
integration 


5. Testning och 
utrullning 


Egenutveckling 
Egenkontroll över planering 
samt att NRM är en liten 
organisation vilket förenklar 
involvering och förankring. 


Oklart huruvida det finns 
kompetens för denna typ av 
uppgift samt att det saknas 
strategier och långsiktiga planer 
för IT-funktionen inom NRM. 
Relativt liten organisation med 
likartade arbetsuppgifter vilket 
förenklar identifiering och 
prioritering av krav. 

Finns ingen struktur och metod 
för kravhantering idag. 
Bristande erfarenhet av 
samverkan mellan enheterna i 
liknande arbetsuppgifter. 

God insyn i den egna 
verksamheten och kan därför 
anpassa design och 
konfiguration. 


Saknas egen kompetens och 
riktlinjer för informations- och 
IT-arkitektur. Begränsad till 
programmeringsspråk och 
tekniker som finns internt vilket 
ej behöver överensstämma med 
vad som är bäst för NRM på 
sikt. 


Utvecklar ett eget system och 
kan därför anpassa det efter 
verksamhetens unika behov 
samt har kontroll över inriktning 
för framtida lösning och egna 
resurser. 

Begränsad kompetens och 
kapacitet inom 
programmeringsspråk och IT- 
utveckling. 


Egen kontroll av infrastruktur 
och resurser för testning. Bättre 
insyn och transparens av test 
och eventuella brister av tester. 


Inköp av lösning eller tjänst 
Extern expertis kan ge stöd kring 
facilitering och utveckling av 
långsiktig plan. Fördelaktigt givet 
att NRM idag saknar en långsiktig 
plan för IT generellt och målbild 
för DINA specifikt. 

Risk att föreslagen plan och 
lösning inte är anpassad till NRMs 
verksamhet och förutsättningar. 


Standardiserade och välbeprövade 
metoder för identifiering, 
verifiering och hantering av krav. 


Kräver stöd i prioritering av 
identifierade krav från NRM. Om 
NRM inte kan prioritera krav finns 
risk att lösningen ej uppfyller 
verksamhetens kritiska behov. 
Möjlighet att ta in bra kompetens, 
standardiserade och välbeprövade 
metoder. Vid inköp av lösning 
förkortas tiden till implementering 
av system. 

Risk att NRM blir beroende av en 
extern part för att kunna 
vidareutveckla sin lösning. Vid 
inköp av extern lösning kan det 
finnas begränsningar i befintlig 
och framtida funktionalitet. Ställer 
höga krav på inköpsförmåga hos 
NRM för att värdera olika externa 
lösningar eller företag. 

Möjlighet att tillsätta expertis som 
har rätt kompetens att utveckla 
önskad lösning. Möjlighet att 
dimensionera 
projektorganisationen utifrån 
önskad tidslinje. 

Risk att skapa beroende av 
externa leverantörer eller 
begränsas av teknisk 
funktionalitet för den inköpta 
lösningen. 

Beställare kan tydligt kravställa 
vad system och lösning ska 
uppfylla. Möjlighet att använda 
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6. Underhåll och + 
support 


7. Avveckling + 


Risker och 
kostnader 


Finns ej förutsättningar för detta 
idag då IT inte kontroller 
testmiljöer och utförda tester. 
Oklart om de testmiljöer som 
finns är ändamålsenliga utifrån 
målbilden. 

Supporten kan utvecklas till att 
vara lättillgänglig och nära 
användarna. IT-enheten 
underhåller idag egenutvecklade 
system. 


IT-enheten har idag ingen 
support och saknar därmed 
förutsättningar för att kunna 
leverera denna typ av tjänst. 
Troligen en högre kostnad för 
support och underhåll per 
användare. 

Egen kontroll av lösningen och 
därmed möjlighet att skapa 
funktionen (migrering) utifrån 
NRMSs behov. 


Risk att förståelse av lösning är 
personberoende och därmed 
försvårar framtida migrering och 
avveckling av system. 


Kostnaden av egenutveckling av 
system är generellt lägre 
förutsatt att rätt kompetens och 
förutsättningar finns. I 
avsaknad av dessa ökar risken 
nämnvärt och därmed 
kostnaderna, vilket DINA är ett 
exempel på. 


välbeprövade metoder och tillgång 
till rätt kompetens. 

Risk att omfattningen av 
testningen kan begränsas p.g.a. 
kommersiella avtal och tidigare 
överenskommelser. 
Transparensen ej lika god som vid 
egenutveckling. 

Extern aktör levererar support och 
underhåll och säkerställer att 
systemet uppdateras enligt 
överenskommelse och avtal. NRM 
undviker att behöva bygga upp 
denna förmåga inom sin 
organisation idag. Billigare med 
support och underhåll då 
kostnader fördelas mellan flera 
organisationer (användare). 
Beroende av extern part för 
underhåll och support. 


Kravställning och avtal om att 
framtida lösning ska kunna 
hantera avveckling och migrering 
minskar risken att gå miste om 
information och data. 

Risk att kunskap och insikter om 
system går förlorat om extern 
aktör går i konkurs. Beroende av 
extern part för migrering och 
avveckling. 

Dyrare att köpa in konsulter för 
utveckling i jämförelse med 
lönekostnad för egen personal. 
Men med en tydlig kravbild och 
bra styrning kan den totala 
kostnaden bli lägre. Vidare 
minskar riskerna avsevärt via 
avtal där kostnader sker mot 
leveranser. 


Tabell 12: För- och nackdelar mellan egenutveckling och inköp av systemlösning utifrån Naturhistoriska 


riksmuseets förutsättningar 


Se kapitel 7 för slutsatser och kapitel 8 för slutliga rekommendationer. 
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11. 


APPENDIX B - TERMINOLOGI 


Databas 
En samling av information som är strukturerad på ett sådant sätt att det ska vara lätt att komma 
åt en specifik del av informationen. 


Samlingshanteringssystem 
IT-system för att hantera (spara, sökning, dela) information om samlingar. 


Lösning vs. system 
System är ett program eller applikation med ett syfte. En lösning är flera applikationer, system 
eller databaser som tillsammans har ett gemensamt syfte. 


Datamodell 

En datamodell är en abstrakt modell som organiserar element av data och standardiserar hur de 
förhåller sig till varandra och till egenskaperna hos den verkliga världen (systemet eller 
databasen). 


Informationsmodell 

En informationsmodell inom mjukvaruteknik är en representation av begrepp och förhållanden, 
begränsningar, regler och operationer för att specificera data (information) för ett valt 
diskursområde. Vanligtvis specificerar det förhållanden mellan olika saker, men kan också 
innehålla relationer med enskilda saker. 


Funktionalitet 
En funktionalitet i ett system avses en behandling av data för att utföra en mindre uppgift, 
exempelvis att skriva ut data från digitalt till papper. 


Process 
En process är repetitiv och består av en uppsättning sammanlänkade aktiviteter som utförs av en 
organisation i syfte att leda till ett värdefullt utfall (mål). 


Aktivitet 
En aktivitet är en handling som utförs av en medarbetare som en del av en process, exempelvis 
"skicka rapport”. 


Information 

Information (data) uttrycker kunskap eller budskap i en konkret form, och består ofta men inte 
alltid av en samling fakta. Ett objekt beskrivs och har flera olika typer av information kopplat till 
sig i ett samlingshanteringssystem. 


DINA 
Digitalt informationssystem för naturhistoriska samlingar. 


DINA-projektet 
Det övergripande namnet på projektet omfattar grupperingarna DINA-INT och DINA-SE samt 
kopplingar mellan dessa projekt och deras verksamhet. 


DINA-SE 


De svenska deltagarna i DINA-programmet samt de delprojekt de ansvarar för (Naturhistoriska 
riksmuseet, Stockholm; Evolutionsmuseet, Uppsala; Biologiska museet, Lund; Göteborgs 
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naturhistoriska museum och Herbarium GB, Göteborg). Målet är att ersätta ett flertal 
egenutvecklade samlingsdatabaser med ett webbaserat nationellt system, som gör det möjligt för 
alla deltagande institutioner att effektivt hantera sina samlingar och samtidigt göra information 
tillgänglig för forskare och allmänhet. 


DINA-INT 

De internationella samarbetsparterna i DINA-programmet samt de delprojekt som de är ansvariga 
för. Kärnmedlemmarna är Naturhistoriska riksmuseet, Sverige; Agriculture and Agri-Food Canada, 
Kanada; Museer fär Naturkunde, Tyskland. Som associerade medlemmar: Tartu Natural History 
Museer, Estland; Statens Naturhistoriska Museer, Danmark; Royal Botanical Garden, 
Storbritannien. 


DINA-Web 

Ett gemensamt, enhetligt, webbaserat samlingshanteringssystem som består av flera 
webbmoduler tillgängliga via öppna API:er och en databas inspirerad av Specify-datamodellen. 
Systemet ska tillhandahålla de kärnmoduler som krävs för en lättillgänglig, säker och 
kostnadseffektiv hantering för naturhistoriska samlingar. DINA-Web är under utveckling. 


Specify/DINA-Specify 


Ett samlingshanteringssystem från en extern leverantör som använts och vidareutvecklats som en 
del av DINA-projektet. Specify finns i flera versioner inom NRM och DINA-medlemmar. 
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12. REFERENSER 


Nedan listas de intervjuer och huvuddokument som ligger till grund för rapporten. 


Intervjuer 


Följande personer har blivit intervjuade avseende deras involvering, arbete och syn på DINA- 


projektet. 


Jörgen Langhof 
Fredrik Ronquist 
Kjell Arne Johanson 
Mats Lund 

Per Ericson 

Lisa Sundström 
Markus Englund 
Ingimar Erlingson 
Joakim Malmström 
Mats Eriksson 


Dokumentation 


Representant Geo 

Initiativtagare DINA, tidigare enhetschef BIO 
Enhetschef Zoologienheten 

Chef för IT-enheten 

Tidigare chef för forskningsavdelningen 
DINA-gruppen 

DINA-gruppen 

Utvecklare, jobbat i DINA-gruppen 
Överintendent 

Chef för evolutionsmuseet i Uppsala, 
representant i DINA-SE 


Nedan listas de dokument som i största utsträckning ligger till grund för rapporten. 


Namn på dokument 


Diarienummer 


Ansökan om medel till biologiska samlingar 
2010 

Ansökan om medel till biologiska samlingar 
2016 

Beslut DINA 2017-2019 

Redovisning av projektet Stöd till biologiska 
samlingar 

Redovisning av projektet Stöd till biologiska 
samlingar 2017-2019, från Svenska 
artprojektet, 2017 

Summerande dokument för datakällor på 
samtliga enheter inom FA 

IT-2000 Databaser på Naturhistoriska 
riksmuseet 


DINA förstudierapport (Fas 1) 

DINA förstudierapport (Fas 2) 

Gemensamt system för samlingsdatabaser 
Rapport 

Uppföljning och utvärdering av projekt 
DINA/IRIS 

Questions about the future, potential 
strategies and project phases 


Diarienummer saknas, avsändare Per Ericson 
4.1-272-2016 


4.1-272-2016 
4.1-272-2016 


4.1-176-2016 
4.1-272-2016 


Diarienummer saknas, avsändare samtliga 
enheter inom FA 

Diarienummer saknas, avsändare Thord 
Fransson (RC), Sven Kullander (VE), Eva 
Stengård (IT), Sabine Stöhr (EV), Anders 
Tehler (Kbo), Lars Werdelin (PZ) (delvis: Arne 
Anderberg (Fbo), Ove Johansson (PB)) och 
Anders Roslund (konsult) 

Diarienummer saknas, avsändare Per Hedman 
Diarienummer saknas, avsändare Eva Stengård 
Diarienummer saknas, avsändare Torsten 
Eriksson 

Diarienummer saknas, avsändare Groth & 
Groth AB 

Diarienummer saknas, avsändare 
representanter för DINA-INT 
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Synpunkter på dokumentet ”DINA-projektets 
produktleveranser 2019” 


Redovisning av uppdrag till chefen för 
avdelningen för forskning och samlingar (FA- 
C) om framtagande av underlag för 
långsiktigt beslut kring gemensamt 
samlingshanteringssystem vid 
Naturhistoriska riksmuseet 

Project plan DINA-IRIS development 
Synpunkter på DINA-projektet från BIO 
Fördelar och risker med fortsatt 
egenutveckling av ett gemensamt 
samlingshanteringssystem 

Hur ska vi nå gemensam samlingshantering? 


Informatics Infrastructure at the Swedish 
Museum of Natural History: A Review 
Summering av vad som levererats inom 
DINA/IRIS-projektet per 2018-12-31 


Diarienummer saknas, avsändare Markus 
Englund, Lisa Sundström, Ida Li, Fredrik 
Olovsson, Anton Öberg 

4.1-727-2018 


4 .1 4.1-561-2016 

Diarienummer saknas, avsändare bioenheten 
Diarienummer saknas, avsändare Markus 
Englund, Ida Li, Fredrik Olovsson, Lisa 
Sundström, Anton Öberg 

Diarienummer saknas, avsändare Markus 
Englund, Lisa Sundström 

Diarienummer saknas, avsändare Fredrik 
Ronquist 

Diarienummer saknas, avsändare Markus 
Englund, Ida Li, Fredrik Olovsson, Lisa 
Sundström 
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